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Abstract 

Multi-mode real-time systems are those which support applications with different modes of operation, where 
each mode is characterized by a specific set of tasks. At run-time, such systems can, at any time, be requested 
to switch from its current operating mode to another mode (called "new mode") by replacing the current set of 
tasks with that of the new-mode. Thereby, ensuring that all the timing requirements are met not only requires 
that a schedulability test is performed on the tasks of each mode but also that (i) a protocol for transitioning 
from one mode to another is specified and (ii) a schedulability test for each transition is performed. We propose 
two distinct protocols that manage the mode transitions upon uniform and identical multiprocessor platforms 
at run-time, each specific to distinct task requirements. For each protocol, we formally establish schedulability 
analyses that indicate beforehand whether all the timing requirements will be met during any mode transition 
<^ of the system. This is performed assuming both Fixed-Task-Priority and Fixed- Job-Priority schedulers. 

(D 
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O 1 Introduction 

Hard real-time systems require both functionally correct executions and results that are produced on time. Con- 
trol of the traffic (ground or air), control of engines, control of chemical and nuclear power plants are just 
some examples of such systems. Currently, numerous techniques exist that enable engineers to design real-time 
systems while guaranteeing that all the temporal requirements are met. These techniques generally model 
Q each functionality of the application by a recurrent task, characterized by a computing requirement, a temporal 

I— I deadline and an activation rate. Commonly, real-time applications are simply modeled by a single and finite 
set of such tasks. However, practical applications often exhibit multiple behaviors issued from several operating 
<^ modes (e.g., an initialization mode, an emergency mode, a fault recovery mode, etc.), where each mode is 
characterized by its own set of functionalities, i.e., its set of tasks. During the execution of such multi-mode 

OS real-time applications, switching from the current mode (called the old-mode) to any other mode (called the 
new-mode) requires to substitute the currently executing task set with the set of tasks of the new-mode. This 
substitution introduces a transient phase, where tasks of both the old- and new-mode may be scheduled simul- 

CN taneously, thereby leading to a possible overload that can compromise the system schedulability — indeed it can 
be the case that both the old- and new-mode have been asserted schedulable by the schedulability analysis but 
the transition between them fails at run-time. 
. . The scheduling problem during a transition between two modes has multiple aspects, depending on the 

^ ^ behavior and requirements of the old- and new-mode tasks when a mode change is initiated. Upon a mode 

^ change request: 

•an old-mode task may be allowed to be immediately aborted or, on the contrary, can be required to com- 
plete the execution of its current active job (so that it preserves data consistency for instance). Using 
scheduling algorithms such as the one considered in this study, we will prove in Section [s] that aborting 
tasks upon a mode change request does not jeopardize the schedulability of the mode transitions. Hence, 
we assume in this paper the most problematic scenario in which every old-mode task must complete its 
current active job (if any) when a mode change is requested. 

• a new-mode task either requires to be activated as soon as possible when a mode change is requested or 
requires to be activated only when all the active jobs issued from the old-mode have totally completed 
their execution. 

Finally, there may be some tasks (called mode-independent tasks in the literature) that belong to more than 
one mode and such that their activation pattern must not be jeopardized during the transition between those 
mode^ However this paper will consider only systems that do not include such tasks. 

^In practice, mode-independent tasks typically allow to model daemon functionalities. 
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Transition scheduling protocols for tasks without mode-independent tasks are often classified with respect to 
the way they schedule the old- and new-mode tasks during the transitions. In the literature (see for instance I134II 
which considers uniprocessor systems), the following definitions are used. 

Definition 1 (Sjmchronous/asynchronous protocol [ 34 1 ) A transition protocol is said to be synchronous if it 
schedules new-mode tasks only when all the old-mode tasks have completed. Otherwise, it is said to be asynchronous. 

Definition 2 (Protocol with/without periodicity |34J) A transition protocol is said to be "with periodicity" if 
and only if it is able to deal with mode-independent tasks. Otherwise, it is said to be "without periodicity". 

1.1 Related work 

Numerous transition protocols have been proposed for uniprocessor platforms (a survey about this concern is 
presented in [34|). In such environments, existing researches ||341l25|[33ll have shown that even if two modes 
of the application have been proven feasible, the transition between the two modes can cause violation of timing 
constraints, hence needing explicit analyses. Such analyses have been proposed in [35 1, considering the popular 
Rate Monotonic Algorithm. Unfortunately three years later, this analysis was shown optimistic [,39J in the sense 
that some unfeasible task sets could be asserted schedulable. In the same paper [|39L the authors improved 
the previous analysis and proposed a new one which considers the popular Deadline Monotonic Algorithm. An 
analysis of sporadic tasks scheduled on EDF is known as well [2|. In [,37J . the authors proposed an analysis 
which considers Fixed-Task-Priority scheduling (FTP), Earliest-Deadline-First II26II scheduling and arbitrary task 
activation pattern. Furthermore, for applications that were initially proven not schedulable during the transition 
phases, they derived the required offsets for delaying the initialization of transition between two modes in order 
to make the application schedulable. 

Among the uniprocessor synchronous protocols, the authors of [[3] 1381 |34ll proposed the following protocols. 

t> The Minimum Single Offset Protocol (MSO) II34II where the last activation of each old-mode task completes 
and then, the new-mode tasks are released. 

t> The Idle Time Protocol (IT) P381 where the periodic activations of the old-mode tasks are suspended at the 
first idle time-instant occurring during the transition and then, the new-mode tasks are released. 

The Maximum-Period Offset Protocol (MPO) ||3]| where the delays of first activation of each new-mode task 
is equal to the period of the less frequent task in both modes. 

Among the uniprocessor asynchronous protocols, the authors of [|391 1321 12]| proposed the following protocols. 

A protocol without periodicity II32II where tasks are assigned priorities according to the Deadline Monotonic 
Scheduling algorithm and are scheduled with time offsets during the mode change only. 

i> A protocol with periodicity has been introduced by Sha et al. in 11361 . assuming Fixed -Task-Priority schedul- 
ing. Then, the authors of [2| extended this protocol to the Earliest Deadline First [26] scheduling algo- 
rithm. 

The authors of II39II introduced a particular protocol which allows tasks to modify their parameters (pe- 
riod, execution time, etc.) during the mode changes. As in 113211 . this study assumes that the tasks are 
scheduled according to the Deadline Monotonic scheduling algorithm. 



1.2 Contribution and paper organization 

In this paper we propose two protocols without periodicity (SM-MSO which is synchronous and AM-MSO which 
is asynchronous) for managing mode transitions during the execution of multi-mode real-time applications on 
muZtiprocessor platforms. Both protocols can be considered as a generalization to multiprocessors of the MSO 
protocol proposed in [|34J . We assume that every operating mode of the application is scheduled by a global, 
work-conserving, preemptive and Fixed-Job-Priority (FJP) scheduling algorithm (formal definitions are given in 



Section 2.41. Some of the results presented here have already been published (see [27| [29l 1311 130II ). It is 
worth noticing that the problem of scheduling multi-mode applications upon multiprocessor platforms is much 
more complex than upon uniprocessor platforms, especially due to the presence of scheduling anomalies (see 
Chapter 5 of [ 1 1 for a definition) and it is now well known that real-time multiprocessor scheduling problems are 
tj^ically not solved by appljdng straightforward extensions of techniques used for solving similar uniprocessor 
problems. 

The paper is organized as follows. Section [2] defines the computational model used throughout the paper. 
Sectionsjs] and |4] describe the synchronous and asynchronous protocols SM-MSO and AM-MSO, respectively. 
Section (sTintroduces some definitions and basic results necessary for the establishment of our schedulability 
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analyses. These four first Sections I2H5] are a common base of the paper, in the sense that these |20] pages 



describe both the models of computation and protocols independently of the platform and scheduler character- 
istics. Then, the four next Sections [6}|9] are each specific to a platform and scheduler model. More precisely, 
they provide a schedulability analysis for both SM-MSO and AM-MSO, assuming in turn identical platforms 
and Fixed -Job-Priority schedulers (in Section [6]), identical platforms and Fixed -Task- Priority schedulers (in Sec- 
tion [7]), uniform platforms and Fixed- Job-Priority schedulers (in Section [s]) and uniform platforms and Fixed- 
Task-Priority schedulers (in Section Finally, Section 10 gives our conclusions and future v^fork, together 
with some remaining open problems. 



2 Models of computation and specifications 

2.1 Application specifications 

We define a multi-mode real-time application r as a set of x operating modes denoted by M^,M^, . . . 
v^fhere each mode M'^ has to execute its associated task set t'' =^ {^f , j • ■ • 1 '^n^} composed of tasks by 
follov^fing the scheduler 5'"'. At run- time, the application is either running in one and only one mode, i.e., it is 
executing only the set of tasks associated to that mode, or it is sv^fitching from one mode to another one. Since 
we do not consider mode-independent tasks in this study, it holds that t'' n =0, V/s 7^ j. 

Each task is modeled by a sporadic and constrained-deadline task characterized by three parameters 
(Cf , D^,T^) — a worst-case execution time C^, a minimum inter-arrival time and a relative deadline < 
— with the interpretation that, during the execution in mode M'^, task rf generates successive jobs rf^ (with 
j = 1, . . . , 00) released at times af ^ such that a^^ > af j_i + (with af^ > 0), each such job has an execution 

requirement of at most C^, and must be completed at (or before) its absolute deadline noted ^ =' ^ + D^. 
In the particular case where ^ = af j_i + Tj^, Vj > 1, the task rj^ is said to he periodic instead of sporadic. In 
the same vein, if Z3f — then the task is said to be implicit- deadline instead of constrained-deadline. 

Definition 3 (Active job) We say that a job t^^ is active at time t if it has been already released (i.e., t < a'^j) 
and it is not completed yet. 

Since we assume Df < Tj', there cannot be two jobs of a same task active at a same time in any feasible 
schedule. All the tasks are assumed to be independent, i.e., there is no communication, no precedence constraint 
and no shared resource (except the processors) between them. In 1.31.1 , we introduced the following concept of 
enabled/ disabled tasks. 

Definition 4 (Enabled/disabled tasks [311 ) At run-time, any task tI of the application can generate jobs if and 
only if tI is enabled. Symmetrically, a disabled task cannot generate jobs. 

As such, disabling a task tJ, prevents future job releases from r^. When all the tasks of any mode are 
enabled and all the tasks of all the other modes are disabled, the application is said to be running in mode AP 
(since only the tasks of mode r* can release jobs). We denote by cnablcd(T*, t) and disabled(r', t) the subsets of 
enabled and disabled tasks of t* at time t, respectively. 

2.2 Platform specifications 

Many recent embedded systems are built upon multiprocessor platforms in order to fulfill the high computa- 
tional requirements of applications. As pointed out in [8,9], another advantage of such a choice is the fact that 
multiprocessor systems are more energy efficient than equally powerful uniprocessor platforms. Indeed, raising 
the frequency of a single CPU results in a multiplicative increase of the consumption while adding CPUs results 
in an additive increase. Two distinct multiprocessor architectures are commonly used in the industrial world 
and thus, are considered in this paper: identical and uniform platforms. 

Identical platform. In such multiprocessor platforms, all the CPUs have the same computational capabilities, 
with the interpretation that in any interval of time two CPUs execute the same amount of work (assuming that 
none of them is idling). In the remainder of this paper, any platform composed of m identical CPUs will be 

modeled by tt =^ {tti, 7r2, ... where tt^ denotes the i"' CPU of the platform. 

Uniform platform. In such multiprocessor platforms, the CPUs are allowed to have different computational 
capabilities. That is, a parameter Si is associated to every CPU tt^ with the interpretation that in any time 
interval of length t, CPU Wi executes Si ■ t units of execution (if it is not idling). This parameter can be seen 

^Even though Fixed- Job-Priority schedulers encompass the family of Fixed-Task-Priority schedulers, the particular case of Fixed-Task- 
Priority schedulers is treated separately so that the schedulability analyses are more specific and therefore more accurate. 
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as the execution speed of the CPU. In the remainder of this paper, any platform composed of m uniform CPUs 

is modeled by tt =^ {si, S2, • • • , Sm}, where is the execution speed of CPU tt^. Without loss of generality, we 
assume that Si > Si_i Vi = 2,3,..., m, meaning that CPU tt™ is the fastest CPU while tti is the slowest one. 
For all fc e [1, m], we denote by s(fc) the cumulated speed of the {m — k + 1) fastest CPUs, i.e.. 



Notice that identical platforms are a particular case of uniform platforms where = Sj e [1, m]. In this 
particular case we assume without any loss of generality that Vi: = 1. 

2.3 Mode transition specifications 

while the application is running in any mode AP, a mode change can be initiated by any task of r* or by 
the system itself, whenever it detects a change in the environment or in its internal state for instance. This is 
performed by invoking a MCR(j) (i.e., a Mode Change Request), where AP is the destination mode. We denote 
by tMCR(j) the invoking time of the last MCR(j). From the time at which a mode change is requested to the 
time at which the transition phase ends, and A-P are referred to as the old- and new-mode, respectively. 

At run-time, mode transitions are managed as follows. Suppose that the application is running in mode 
A'P and the system (or any task of t') comes to request a mode change to mode AP , with j =^ i. At time 
tucRij), system entrusts the scheduling decisions to a transition protocol which immediately disables all the 
old-mode tasks, thus preventing them from releasing new jobs. At this time, the active jobs issued from these 
disabled tasks, henceforth called the rem-jobs (for "remaining jobs"), may have two distinct behaviors: either 
they can be aborted upon the MCR(j) or they can complete their execution. From the schedulability point of 
view, we will show that aborting some (or all) rem-jobs upon a mode change request does not jeopardize the 
system schedulability during the transition phase. Consequently, we assume the worst-case scenario for every 
mode transition, i.e., the scenario in which every old-mode task has to complete its last releasedjob (if any) during 
every mode transitior^ The fact that the rem-jobs have to complete their execution upon the MCR(j) brings 
the following problem. Even if both task sets r* and (from the old- and new-mode, respectively) have been 
asserted to be schedulable upon the m CPUs at system design-time, the presence of the rem-jobs may cause 
an overload during the transition phase (at run-time) if all the new-mode tasks of are enabled immediately 
upon the mode change request. Indeed, the schedulability analysis performed beforehand on did not take 
into account the additional work generated by the rem-jobs. To solve this problem, transition protocols usually 
delay the enablement of each new-mode task until it is safe to do so. However, these delays are also subject to 
hard constraints. More precisely, we denote by 2?^(M^) the relative transition deadline of task tI during every 
transition from mode AP to mode AP, with the following interpretation: the transition protocol must ensure 
that tI is enabled not later than time iMCRO) + ^fe(^*)- Finally, when all the rem-jobs are completed and all 
the new-mode tasks of are enabled, the system entrusts the scheduling decisions to the scheduler of the 
new-mode AP and the transition phase ends. 

In short, the goal of any transition protocol is to fulfill the following requirements during every mode change: 

1. Complete each rem-job by its absolute deadline 

2. Enable each new-mode task by its absolute transition deadline tMCR(j) + ^^(-^^0- 

3. Complete each new-mode jot|^T;J ^ by its absolute deadline d-^ ^. 

Definition 5 (Valid protocol 11310 ) A transition protocol A is said to be valid /or a given application t and plat- 
form TT if and only if A meets all the job and transition deadlines during every transition between every pair of 
operating modes of t. 

This notion of "valid protocol" is directly related to that of a "validity test" defined as follows. 

Definition 6 (Validity test [31]) For a given transition protocol A, a validity test is a condition based on the tasks 
and platform characteristics that indicates a priori whether A is valid for a given application r and platform vr. 

■'Aborting a job consists in suddenly stopping its execution and removing it from the system memory. But in the real world, suddenly 
killing a process may cause system failures and the rem-jobs often have to complete their execution. 

■^This requirement is automatically fulfilled for synchronous protocols since no new-mode jobs are scheduled during the mode transitions. 
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2.4 Scheduler specifications 



We consider the global preemptive scheduling problem of sporadic constrained-deadline tasks upon multipro- 
cessor platforms. "Global" schedulers, in contrast to partitioned ones, allow different tasks and different jobs 
of the same task to be executed upon different CPUs. When preemptive, global schedulers allow any job to 
be interrupted at any time prior to completion on any CPU and resumed (possibly later) on any other CPU. 
We consider that every mode Al'' uses its own scheduler denoted by S'^ which can be either Fixed-Task-Priority 
(FTP) or Fixed-Job-Priority (FJP) according to the following interpretations. 

• FTP schedulers assign a priority to each task at system design-time (i.e., before the execution of the 
application) and then at run-time, every released job uses the priority of its task and the priority of a job 
is kept constant until it completes. 

• FJP schedulers assign a priority to each job at run-time (i.e., as soon as it arrives in the system) and every 
job keeps its priority constant until it completes. As such, different jobs issued from the same task may 
have different prioritie^ 

Without loss of generality we assume that, at any time, two active jobs cannot have the same priority. Further- 
more, we consider work-conserving schedulers according to the following definition. 

Definition 7 (Work-conserving global scheduler) A CPU cannot be idle if there is a job awaiting execution. 
Usually, priority-based schedulers assign at each instant in time the m highest priority active jobs (if any) to the m 
CPUs. 

The above definition of work-conserving schedulers encompasses a large family of schedulers, but suffers 
from an important lack of determinism. Indeed for a given set of jobs, multiple (and different) schedules 
can sometimes be derived from the same work-conserving scheduler (and thus from the same job priority 
assignment). The following example illustrates this drawback. 

Example 1 Let us consider the set J of 5 jobs with respective processing time 4, 8, 4, 4 and 6. Suppose that J is 
scheduled on a 2-processors identical platform tt by an FTP, global, preemptive and work-conserving scheduler such 
that Ji > J2 > J3 > J4 > J5. According to Definition^ Figures ^and^depict two possible different schedules 
corresponding to this priority assignment. 
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Figure 1: A possible schedule of Ji, J2, ^/a, Ji and J5. 
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Figure 2: Another possible schedule of Ji, J2, J3, J a and J5. 



In order to get around this lack of determinism, we introduce two refinements of Definition [7] that we name 
weakly and strongly work-conserving schedulers, respectively. Weakly work-conserving schedulers concern only 
identical platforms whereas strongly work-conserving schedulers concern only in uniform (and non-identical) 
platforms. The rationale for introducing these two refinements is to have one and only one possible schedule for 
any given set of synchronou^jobs, multiprocessor platform and job priority assignment. 

^According to these interpretations, FTP schedulers are a particular case of FJP schedulers in which all the jobs issued from a same task 
receive the same priority determined beforehand. 

^The term "synchronous" jobs is commonly used in the literature to refer to jobs that are all ready for execution at the same time. 
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CPUs 




I) time 

Figure 3: For any fixed set of jobs and uniform platform, the schedule generated by any strongly work-conserving 
scheduler forms a staircase. 



Definition 8 (Weakly work-conserving scheduler) A scheduler S is weakly work-conserving if and only if: 

• no CPU idles while there are active jobs awaiting execution, and 

• if there are more than one job awaiting execution and more than one CPU available for the execution of those 
jobs then S assigns the highest priority waiting job to the available CPU with the highest index. 

Property 1 (Unique schedule) For any given finite set J of jobs, any weakly work-conserving scheduler S and 
any identical multiprocessor platform n, there exists one and only one possible schedule of J upon -k following S. 

In order to illustrate this property, let us consider the set of 5 jobs used in Examplejl] a 2-processors identical 
platform tt and any weakly work-conserving scheduler assigning priorities such that Ji > J2 > J3 > J4 > J5. 
The unique possible schedule of J upon tt is the one depicted in Figure [T] Indeed at time 0, CPUs tti and are 
idle and the second condition of Definition|8]imposes Ji to execute on 7r2. From the same rule, J4 must execute 
on TT2 at time 8. Notice that the refinement of "weakly" work-conserving scheduler clarifies only the job-to-CPU 
assignment rule when the highest- priority waiting job has to be dispatched to a CPU. 

Definition 9 (Strongly work-conserving scheduler) A scheduler S is strongly work-conserving if and only if: 

• no CPU idles while there are active jobs awaiting execution, and 

• at every time during the system execution, the job-to-CPV assignment uses the rule: highest priority active 
job upon highest indexed CPU. 

In contrast to the refinement of "weakly" work-conserving schedulers, the "strongly"-refinement clarifies the 
job-to-CPU assignment rule at each time-instant during the system execution. It is essential to keep in mind that 
in our study weakly work-conserving schedulers will be used only on identical platforms whereas strongly work- 
conserving schedulers will be used only on uniform and non-identical platforms. For strongly work-conserving 
schedulers, the concept of migrating jobs to faster CPUs as soon as possible (as specified by the second condition 
of Definition |9]l has been widely used over the years on uniform platforms (see 111211141 1201 1131 [TTI [TSD . This 
refinement is extremely important, especially because it yields the following property. 

Property 2 (Staircase property) Let J denote any finite set of synchronous jobs, n any uniform multiprocessor 
platform and S any strongly work-conserving scheduler In the schedule of J upon n by S, CPU tt^ idles before or 
at the same time-instant as CPU tt^+i for all £ < m. 

Informally speaking, the schedule of J upon tt by 5 forms a staircase (see Figure [s]). 

This property stems from the fact that the CPUs are indexed in such a manner that > Sj Vi > j. Thus, it 
holds from the second condition of Definition [9] that at any instant t, if S idles the i*''-slowest CPU then S also 
idles the j*-^ slowest CPUs for all j < i. Also, it results from the same condition that the z*'' CPU that starts 
idling is always tt, . 

The following definition introduces the fundamental notion of predictability, and Lemmas [T] and |2] are essen- 
tial for the rest of the paper 



6 



Definition 10 (Predictability [24]) Let A denote a scheduler, and let J = {Ji, J2, J3, ■■■} be a potentially infinite 
set of jobs, where each job Ji — {ai,Ci,di) is characterized by an arrival time ai, a computing requirement Ci and an 
absolute deadline di. Let r,; and fi denote the time at which job Ji starts and completes its execution (respectively) 
when J is scheduled by A. Now, consider any set J' = {J{, J2, J3, . . .} of jobs obtainedfrom J as follows. Job J- has 
an arrival time ai, an execution requirement c ■ < c,;, and a deadline di. Let r[ and f[ denote the time at which job 
J[ starts and completes its execution (respectively) when J' is scheduled by A. Algorithm A is said to be predictable 
if and only if for any set of jobs J and for any such J' obtainedfrom J, it is the case that r- < and f[ < fi Vi. 



Informally speaking, Definition 10 claims that an upper-bound on the starting time and on the completion 
time of each job can be determined by analyzing the situation under the assumption that each job executes for 
its WCET. The result from Il22l|24[[23il that we will be using can be stated as follows. 

Lemma 1 (See [22, 24, 23]) On identical multiprocessor platforms, any FJP, global, preemptive and weakly 
work-conserving scheduler is predictable. 

In the same vein, the result from II17II that we will be using can be stated as follows. 

Lemma 2 (See II17II ) On uniform multiprocessor platforms, any FJP, global, preemptive and strongly work-conserving 
scheduler is predictable. 

We use the notation V to refer to a specific job priority assignment. A job priority assignment can be seen 
as a key component of any scheduler, but the definition of a scheduler is more general since, in addition to a 
job priority assignment, a scheduler must also provide specifications like "global or partitioned", "preemptive 
or non-preemptive", etc. For any job priority assignment V, we denote by Ji >-p Jj the fact that job J; has a 
higher priority than Jj according to V, and we assume that every assigned priority is distinct from the others. 
That is, yv,i,j such that i ^ j we have either Ji >-p Jj xor J,; <-p Jj. Similarly, and without any distinction 
with the interpretation given above, we will sometimes use the notations Ji >gk Jj and J,; <gk Jj where 5*^ 
is the scheduler of mode Al'', and we will sometimes use the notations Ji > Jj and Ji < Jj when the job 
priority assignment has no label (for instance, when we will depict some examples of schedules, we will just say 
"Ji > Jj" without giving a name to the job priority assignment). Finally, the problems and solutions presented 
in this paper are addressed under the following assumptions: 

Assumption 1. The set r'^ of tasks of every mode M'^ can be scheduled by S'' on m CPUs without missing 
any deadline. 

Assumption 2. Job migrations and preemptions are permitted and are carried out at no loss or penalty. 
Assumption 3. Job parallelism is forbidden, i.e., jobs execute on at most one CPU at any instant in time. 
t> Assumption 4. For every mode Af * it holds that m < rii, where is the number of tasks in mode AP. 

Regarding Assumption 1, it allows us to focus only on the schedulability of the application during the 
transient phases corresponding to mode transitions, rather than on the schedulability of the application during 
the execution in a given mode. 

Regarding Assumption 4, it is worth noticing that since job parallelism is forbidden and tasks are assumed to 
be constrained-deadline, there are at most n,; jobs active at a same time during the execution of any mode AP. 
As a result, it holds for each mode AP that in every schedulable application where m > Ui, there are always 
m — Tii CPUs that constantly idle. We will see later that these m — Ui idling CPUs are the slowest ones and the 
problem in that case thereby reduces to the same problem upon the subset of the fastest CPUs among these 
m CPUs. 



3 The synchronous protocol SM-MSO 
3.1 Description of the protocol 

The protocol SM-MSO (which stands for "S5Tichronous Multiprocessor Minimum Single Offset" protocol) is an 
extension to multiprocessor platforms of the protocol MSO defined in [I34II for uniprocessor platforms. This 
protocol supports both uniform and identical platforms. The main idea of SM-MSO is the following: upon a 
MCR(j), Vj, all the tasks of the old-mode (say A/*) are disabled and the rem-jobs continue to be scheduled by 
the old-mode scheduler 5' upon the m CPUs. Once all the rem-jobs are completed, all the new-mode tasks (i.e., 
the tasks of r^) are simultaneously enabled. Algorithm [4] gives the pseudo-code of this protocol and Example [2] 
illustrates how SM-MSO handles the mode transitions. 
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Input: : the old mode 
Input: AP: the new-mode 
Input: the rem-jobs 
1: while true do 

2: Schedule the rem-jobs according to 

3: if (any rem-job Jk completes at time f) then 

4: if (active(T', t) = cj)) then 

5: enable all the new-mode tasks of 

6: enter the new-mode IvP 

7: end if 

8: end if 

9: end while 

Figure 4: SM-MSO protocol 
MCRO) 



T^2 


Mode Af ' in progress 


Transition deiay 


Mode A/-^ in progress 














□f 


^1,1 ^4,1 




A 

1,2 








b of 








"1 

No more rem-jot) 

=jAM-M30 enables all the lasks 

[end o! the IranBition phase) 


^"=.1 ''3.1 








Arrival of every jo 


1. 










120 220 time 



Figure 5: Illustration of a mode transition handled by SM-MSO. 



Example 2 Let us consider a platform tt composed of only 2 identical CPUs and an application composed of 2 
modes AP and AP depicted in blue and red, respectively. We assume that these two modes contain only synchronous 
implicit- deadline periodic tasks. The old-mode AP contains 4 tasks with characteristics given in Tableland uses an 
FTP scheduler 5* such that rl >g^ T2 >s^ >gz tI. 



Tasks 


CI 


^i = n 


rl 


40 


120 


rl 


20 


120 


^3 


40 


120 


~4 


60 


120 



Table 1: Characteristics of the tasks in AP. 

The new-mode AP contains 3 tasks tI,t2,t^ and uses an FTP scheduler such that t( >gj >sj t^. The 
characteristics of these tasks are: €{ = 100 and — — 40. The deadline and period of these new-mode tasks 
do not have any importance in this example and we intentionally omitted to specify them. Figure^illustrates the 
SM-MSO transition protocol between these two modes. 

At time 120, every task of AP releases its second job and the scheduler 5' starts the execution of tI ^ and t\ ^ 
on CPU 1^2 and tti, respectively. Then, suppose that the system requests a mode change at time 130. Here starts 
the transition phase from mode AP to mode AP. As specified by the protocol SM-MSO, all the old-mode tasks 
are immediately disabled and the remaining active jobs tI 2, t'2,2 7 '''3 2 2 (named the rem-jobs from this point 

forward) continue to be scheduled according to the old-mode scheduler 5'. These rem-jobs execute until time 220, 
time at which they are all completed. At this instant 220, the condition at line 4 of Algorithm^is verified. Thus, 
SM-MSO enables all the new-mode tasks and starts scheduling the incoming new-mode jobs according to the new- 
mode scheduler S^. Notice that at any time during every transition phase, our protocol SM-MSO allows the system 
(or any task) to request any other mode change. At the very end of the current transition phase (at time 220 in this 
example), SM-MSO enables all the tasks of the mode AP assuming that MGR{z) is the last mode change that has 
been requested. 
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3.2 Design of a validity test 



In order to establish a validity test for the protocol SM-MSO, two key results are required: 

1. It must be proved for every mode transition that disabling the old-mode tasks upon a MCR does not jeop- 
ardize the schedulability of the rem-jobs v^rhen they continue to be scheduled by the old-mode scheduler. 
That is, it must be guaranteed that the absolute deadline j, of every rem-job r* ^ is met during every 
mode transition from every mode AP . 

2. It must be proved for every mode transition that the length of the transition phase can never be larger than 
the minimum transition deadline of all new-mode tasks. Indeed, it follows from this statement and the 
definition of SM-MSO that all the transition deadlines would be met during every mode transition. 

We provided a proof for the first key result in [I31II (the proof is replicated in Section [sj page \17}, and 
this result holds for any uniform platform (including identical platforms). About the second key result, it is 
worth noticing that there is no job release (and therefore no preemption) during every transition phase since 
we consider only FJP schedulers and all the old-mode tasks are disabled upon any mode change request. As a 
consequence, the length of any transition phase corresponds to the time needed to complete all the rem-jobs (this 
clearly appears in Figure [s]). In the literature (and hereafter as well), the time needed to complete a given set 
of synchronous jobs upon a given platform is called the makespan defined as follows. 

Definition 11 (Makespan) Let J = { Ji, J2, . . . , J„} denote any set of n jobs of processing times ci, C2, . . . , c„. Let 
TT denotes any uniform multiprocessor platform composed of m CPUs. Let V denote any job priority assignment 
and S denotes the schedule of J upon n by any vi/ork-conserving scheduler (including weakly and strongly work- 
conserving schedulers) using the priority assignment V. The makespan denoted by ms( J, tt, V) is the earliest instant 
in S such that the njobs of J are completed. 

According to Definition the length of any transition phase corresponds to the makespan generated by 
the set of jobs that are active in the system when the mode change is requested, i.e., the set of rem-jobs. Since 
the value of the makespan obviously depends on the number and processing times of the jobs (as well as on 
the CPU speeds), then the length of any transition phase from any mode AP to any other mode A'P depends 
on both the number of rem-jobs and their remaining processing time at time tMCR(j)- From this observation, 
determining an upper-bound on the makespan requires to consider the worst-case scenario, i.e., the scenario in 
which the number and the remaining processing time of the rem-jobs at time tyicK(j) is such that the generated 
makespan is maximum. This worst-case scenario is thus entirely defined by a specific set of rem-jobs that we 
name the critical rem-job set defined as follows. 

Definition 12 (Critical rem-job set J^^) Assuming any transition from a specific mode A'P to any other mode 
AP, the critical rem-job set J^'^ is the set of jobs issued from the tasks of that leads to the largest makespan. 

For any work-conserving FJP scheduler (including FTP schedulers) and uniform platform (including identical 
platform), we will show that the critical rem-job set J^'^ of every transition from mode AP'- to mode AP is the 
one where each task has a rem-job at time ^mcrO) with a remaining processing time equals to (i.e., the 
WCET of rp. This result is very intuitive: the makespan is as large as the number and processing times of the 
rem-jobs are large. 

In this paper we address the problem of establishing mathematical expressions that provide the maximum 
makespan for any given set of sync/ironou^jobs and especially for the critical rem-job set during each mode 
transition. This intention stems from the fact that the knowledge of the maximum makespan allows us to 
assert (or refute) that every new-mode task will meet its transition deadline during any mode transition using 
SM-MSO, thus ensuring the validity of SM-MSO for a given application t and platform tt as follows. 

Validity Test 1 (For protocol SM-MSO) For any multi-mode real-time application t and any uniform multipro- 
cessor platform TT, protocol SM-MSO is valid provided that, for every mode AP, 



where T"^ is the job priority assignment derived from the old-mode scheduler and ms{J.^'^,7:,V^) is an upper- 
bound on the makespan, considering the set J^'^ of jobs, the platform tt and the job priority assignment V\ 

^During every mode transition, the considered jobs are assumed to be synchronous because every rem-job is active and ready to execute 
upon the mode change request. 




(2) 
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The above expression can be interpreted as follows: all the transition deadlines will be met during the 
execution of the system if, for every mode A'P, the maximum makespan (i.e., the maximum transition latency) 
generated by the rem-jobs issued from the tasks of t' cannot be larger than the minimum transition deadline of 
every task of every mode . 

This validity test is a sufficient condition that indicates, a priori, if all the deadlines will be met during all 
possible mode changes using the protocol SM-MSO. Unfortunately, to the best of our knowledge, the prob- 
lem of determining the maximum makespan has never been studied in the literature. Rather, authors usually 
address the problem of determining a job priority assignment that minimizes the makespan II21I |19L The 
goal in that framework being to ultimately reduce the completion times of the jobs as much as possible. This 
problem of finding priorities that minimize the makespan can be cast as a strongly NP-hard bin-packing prob- 
lem II21I I191 for which numerous heuristics have been proposed in the literature. On the contrary, we provide in 
Sections [6}|9] different upper-hounds on the makespan, assuming in turn identical platforms and FJP schedulers, 
identical platforms and FTP schedulers, uniform platforms and FJP schedulers and finally, uniform platforms and 
FTP schedulers. 



3.3 FTP schedulers vs. FJP schedulers 



As mentioned in Section 2.4 FTP schedulers are a particular case of FJP schedulers. However the remainder 
of this study distinguishes between these two scheduler families because FTP schedulers allow to determining 
a more precise upper-bound ms{J.^'^,TT,'P^) than FJP schedulers. The reason of this stems from the fact that 
the priority of each task (and thus the priority of every job) is known at system design-time for FTP schedulers 
whereas it is unknown beforehand for FJP schedulers. 

At first blush, assuming that the job priority assignment is unknown for FJP schedulers can seem inconsis- 
tent since during every mode transition, we consider the critical rem job set in the computation of ms{J^'^, vr, V^) 
(and this critical rem-job set is determined at system design-time). Therefore, it could be thought that can 
simply be derived from J^'^. But this intuition is erroneous because for a given FJP scheduler, several job prior- 
ity assignments can be derived from the same critical rem-job set as shown in the following example. Actually, 
given set of jobs, we are not aware of any job priority assignment leading to the maximum makespan. 

Example 3 Let us consider a platform n composed of only 2 identical CPUs and an application r composed of 2 
modes A'P and IvP. Suppose that a mode change is requested from AP to AP and the old-mode scheduler 5' is 
EDF. The old-mode AP contains 3 tasks with characteristics given in Table^ 



Tasks 


CI 


— 


r'i 


5 


15 


ri 


5 


16 


rl 


7 


18 



Table 2: Characteristics of the tasks in AP. 



As introduced earlier, the critical rem-job set for this mode transition is given by J^'^ = >/2, ^^3} wit/i 
processing time C\^C\ and C\, respectively. This will be formally proved in Corollary^ (on page 19 J, assuming 
any FJP scheduler and any uniform platform. Actually, this critical rem-job set specifies only the processing time of 
the jobs, not the release time, neither the absolute deadline. Consequently, different job priority assignments can 
be derived from J^'^. We depict two of them in Figures^and^ In both figures the time is relative to the instant 
*MCR(j) ^i-fiv ^MCRO") = 0^- '^^^ release time and the absolute deadline of each job are denoted by and d^^, 
respectively. These two job priority assignments are obtained as follows. 

Job priority assignment 1. If we assume that the three jobs are released exactly at the MCR invoking time 

*MCR(j>_i-2v fli = ^2 = 03 = ^MCR(j)^ f''^" f''^ absolute deadline of each job Ju is given by dk tyiGKU) + ^k- 
Figure^ the deadline of each job is thus: di ~ 15, d2 = 16 and = 18 and according to EDF, this leads to the 
job priority assignment Ji >edf J2 >edf Js (and to a makespan of 12). 

Job priority assignment 2. Starting from the previous release pattern in which all the jobs are released simulta- 
neously at time t^cRUy one can slightly move backward the release time of job J3 (for instance) in such a manner 



that J-i is released at time t 



MCR(i) 



5 (see FigureWV. Its absolute deadline is thus shifted to time t 



MCR(j) 



13 



and since no assumption is made about the schedule before time tMCR(j)^ can suppose that J3 did not execute 
before iMCRO)- Therefore, the processing time of J3 at time ^mcrO) is = 5 and the job priority assignment 
resulting from this new release pattern is J3 >edf J2 >edf Ji (leading to a makespan of 10). 
In the particular case of EDF, shifting the absolute deadline of these three jobs by distinct amplitudes can modify 
their relative priorities and a possibly large number of job priority assignments can be derived from the same critical 
rem-job set J^'^. 
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Jl 
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Figure 6: Assuming that the three jobs are released simuhaneously upon the MCR(j) allows to derive a first job 
priority assignment. 



TTi 
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^3 



Jl 



J2 
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Figure 7: Another job priority assignment can be derived by slightly modifying the release pattern of the jobs. 
Note that this modification leads to another makespan. 



Because the prior knowledge of the critical rem-job set does not allow determining a unique job priority 
assignment, FJP schedulers require to consider every possible job priority assignment in order to determine 
an upper-bound on the makespan. Hence, we refine the notation of ms( J, tt, T'') as follows: the upper-bound 
on the makespan is denoted by ms(J, tt,?^) when V is explicitly specified (in the context of FTP scheduler) 
and by ms( J, tt) otherwise (in the context of FJP scheduler), with the interpretation that for every job priority 
assignment X: 

^ns{J, tt) > nis( J, TT, X) 

It goes without saying that the prior knowledge of the jobs priority assignment allows for establishing tighter 
upper-bounds on the makespan, i.e., the upper-bound ms{J,n,V) is tighter than ms(J, tt). From these refined 
notations. Expression [2] of Validity Test[T]can be rewritten as 

msiJr, 7T) < min | min {vi {AP)} ] 

for FJP schedulers, and as 

ms(J;^^7^,P') < mini min (vl{M')\\ 

j^i I l<fc<nj I J J 

for FTP schedulers, where V is the job priority assignment derived from the old-mode FTP scheduler 5*. 



4 The asynchronous protocol AM-MSO 
4.1 Description of the protocol 

The protocol AM-MSO (which stands for "As5Tichronous Multiprocessor Minimum Single Offset" protocol) is an 
asynchronous version of the protocol SM-MSO. This protocol supports both uniform and identical platforms. 
The main idea of this second protocol is to reduce the delay applied to the enablement of the new-mode tasks, 
by enabling them as soon as possible. In contrast to SM-MSO, rem-jobs and new-mode tasks can be scheduled 
simultaneously during the transition phases according to the scheduler 5''^"'^ defined as follows: (i) the priorities 
of the rem-jobs are assigned according to the old-mode scheduler; (ii) the priorities of the new-mode jobs are 
assigned according to the new-mode scheduler, and (iii) the priority of each rem-job is higher than the priority 
of every new-mode job. 

Formally, suppose that the system is transitioning from mode M°^'^ to mode M'^™ and let Ji and Jj be two 
active jobs during this transition. According to these notations we have Jj >5tran3 if and only if one of the 
following conditions is satisfied: 

( Jj- e M°^'^ and J, e M"™) 
or ( g Af°'^ and J, e M°''^ and J^ >5oid J,) 
or (Jj e Af'^'=* and Ji e AJ"°" and Jj >5„ow J,) 
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AM-MSO proceeds as follows: upon a MCR(j), Vj, all the old-mode tasks are disabled and the rem-jobs 
continue to be scheduled by 5' (assuming that Af ' is the old-mode). Whenever any rem-job completes (say at 
time t), if there is no more waiting rem-jobs AM-MSO immediately enables some new-mode tasks, in contrast 
to SM-MSO which waits for the completion of all the rem-jobs. In order to select the new-mode tasks to enable 
at time t, AM-MSO uses the following heuristic: it considers every disabled new-mode task by non-decreasing 
order of transition deadline and enables those which can be scheduled by upon the current available CPUs, 
i.e., the CPUs that are not running a rem-job and are therefore available for executing some new-mode tasks. 
The following example illustrates how AM-MSO manages mode transitions. 

Example 4 Let us consider the same task sets as in Example^ Figure^illustrates the AM-MSO transition protocol 
on a 2-processors platform. 
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Figure 8: Illustration of a mode transition handled by AM-MSO. 



Similarly to protocol SM-MSO, AM-MSO schedules the rem-jobs according to the old-mode scheduler from time 
tucRU) ~ ^^^^ ^- '^^^^ ft'^s rem-job 2 completes on CPU tti and there is no more waiting rem- 

jobs. Here AM-MSO reacts differently from SM-MSO; it scans every disabled task of (in non-decreasing order 
of transition deadline) and enables some of them in such a manner that the resulting set of enabled new-mode tasks 
can be scheduled by upon 1 CPU (since at this time t, only the CPU tti is available for executing some new-mode 
tasks). We actually have no guarantee that scanning all the disabled tasks in non-decreasing order of transition 
deadline is optimal, but this heuristic appears as the most intuitive choice. At time 220, AM-MSO performs the 
same treatment as at time t. But since we assumed that every task set t^, Vfc, is schedulable by S'^ on tt, we know 
that all the remaining disabled new-mode tasks can be enabled at this time 220. 

Notice that, in contrast to SM-MSO, the protocol AM-MSO allows mode changes to be requested during the 
mode transitions only until some new-mode tasks have been enabled (the instant t in Figure [8]l. Indeed, if the 
system is transitioning from any mode M* to any other mode and a mode change is requested to any mode 

before time t, then AM-MSO can consider that the system is transitioning from mode AP to mode and 
the new-mode therefore becomes the mode AP. However after time t, some tasks of mode JVP have already 
been enabled and AM-MSO does not allow the system to request any other mode change until the end of the 
transition phase from AP to AI\ i.e., until all the tasks of mode AP are enabled. 

In order to determine whether a task can be safely enabled, protocol AM-MSO uses a binary function 
sched(7r, S, r^) that returns True if and only if the task set is schedulable by S upon tt. This function is 
essential as we must always guarantee that all the deadlines are met for all the jobs in the system, including 
the deadlines of all the new-mode jobs. Considering a specific scheduler S, such a function can be derived 
from schedulability tests proposed for S in the literatur^ Algorithm [9] provides a pseudo-code for protocol 
AM-MSO. 

Observation 1 The whole "if-else-endif" block within lines 1 1-1 7 could be replaced with tt^^' -s— tt^^^ U {nm-r} 
adding iTm-r (instead of -Kg) to tt**^' does not make any difference ifnis identical. However, we preferred to provide 
the reader with this longer version of the algorithm for sake of pedagogy. The shorter version explained here will be 
used in the Validity Algorithm \10\presented on page 15 



^To the best of our knowledge, there is no efficient necessary and sufficient schedulabihty test for any multiprocessor scheduler that 
complies with the requirements specified in Section [Z4| Theodore Baker has proposed in |6] a necessary and sufficient schedulability test 
for arbitrary-deadline sporadic tasks scheduled by Global-EDF but its time-complexity is very high so only small applications can be tested. 
Fortunately, many sufficient schedulability tests have been proposed for scheduler such as Global-EDF (see for instance 1 5l [71 113111011161 ) 
and Global- DM (see for instance l4l [T2l[TT1 ). 
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Input: M': the old mode 
Input: A/J : the new-mode 
Input: the rem-jobs 

Input: t: the current time during the transition 
Input: tt: the platform (uniform or identical) 

1: if (t is the MCR invoking time) then 

2: Disable all the tasks of r' 

3: Sort the task set "disabled(r^ , t)" by non-decreasing order of transition deadlines 

4: tt'^^' ^ 

5: end if 

6: Schedule the rem-jobs according to S^'^'^'^^ 

7: if (any rem-job completes at t on any CPU tt^) then 

8: r <r- number of active rem-jobs at time t 

9: if (r < m) then 

10: /'■ Due to the completion of Jk, one CPU ^ tt**^' becomes available. */ 
11: if (tt is identical) then 

12: /* The scheduler is weakly work-conserving. Thus, the CPU that becomes available is tt^ 

V 

13: tt"*^' tt"*^' U {ne} 

14: else 

15: /* The scheduler is strongly work-conserving. Thus, the CPU that becomes available is the 

{m-rf^ slowest CPU. V 

16: Tt'^^I ^ TT^^l U {iTm-r} 

17: end if 

18: end if 

19: for each t,} e disabled (t-^ , do 

20: T*'='"P ^ enabled(TJ' ,t)u{4} 

21: if (sched(7r*^\ , t^^^'p)) then 

22: enable 

23: end if 

24: end for 

25: if (r = 0) then 

26: enter the new-mode 

27: else 

28: Schedule all the rem-jobs and new-mode jobs according to 5*'^*'"^ 

29: end if 

30: end if 

Figure 9: AM-MSO protocol 
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4.2 Design of a validity test 

For a given application r and platform tt, the main idea to determine whether AM-MSO allows to meet all 
the transition deadlines is to run Algorithm [9] for every possible mode transition, while considering the worst- 
case scenario for each one — the scenario in which the new-mode tasks are enabled as late as possible. From 
our definition of protocol AM-MSO, we know that every instant at which some new-mode tasks are enabled 
corresponds to an instant at which at least one CPU has no more rem-job to execute, i.e., an "idle-instant" 
defined as follows. 

Definition 13 (Idle-instant idlefc( J, tt,V)) Let J — { Ji, J2, • ■ • , Jn} be any finite set ofn synchronous jobs. Let n 
be a uniform multiprocessor platform and let V be the job priority assignment used during the schedule of J upon 
TT. If S denotes that schedule then the idle-instant idlefc( J, -KjV) (with k = 1, . . . ,m) is the earliest instant in S such 
that at least k CPUs idle. 

By definition of the protocol AM-MSO, and in particular from the definition of 5*'^'*"'', a new-mode job never 
preempts a rem-job during the transition phases. Thereby, during every transition phase, new-mode tasks are 
enabled at each idle-instant idlefc( J, tt, V) (Vfc = 1, . . . , m) where J is the set of rem-jobs at the MCR invoking 
time and V is the job priority assignment derived from the old-mode scheduler when the mode change is 
requested. For obvious reasons, the exact values of these idle-instants depend on both the number of jobs in J 
and their actual execution times. Therefore, these exact value cannot be determined at system design-time and 
the main idea of our validity test is the following. 

First, for every mode we determine the set J of rem-jobs that leads to the largest idle-instants idle^ ( J, tt, V) 
(Vfc e [1, m]). From this point forward, we thus refine the definition of the critical rem-job set as follows. 

Definition 14 (Critical rem-job set J^"^) Assuming any transition from a specific mode AP to any other mode 
AP, the critical rem-job set J^'^ is the set of jobs issued from the tasks of that leads to the largest idle-instants. 

As it will be shown in Corollary [l] (page 19 1, the critical rem-job set J^'^ of every mode Af * is the one that 
contains one job for each task and such that every job Ji e J^'^ has a processing time equals to C}, i.e., 
the WCET of r^'. Informally speaking, the worst-case scenario during any mode transition is the one in which 
(i) every old-mode task releases a job exactly when the mode change is requested and (ii) every released job 
executes for its WCET. 

Second, we determine (for any given set J of jobs) an upper-bound on each idle-instant idlefc(J, tt,?^) (for 
k — 1, 2, . . . , m). As in the previous section (and for the same reason), we distinguish between FTP and FJP 
schedulers. That is, for FTP schedulers we focus on determining an upper-bound idlcj,(J, tt, T') on each idle- 
instant idlefe( J, TT, V) (for fc = 1, 2, . . . , m) assuming that the job priority assignment V is known beforehand, 
whereas for FJP schedulers, we determine an upper-bound idle/c(J, tt) on each idle-instant idlefc(J, tt,?^), with 
the interpretation that for every job priority assignment X: 

idlefe(J,7r) > idlefc( J, tt, A") 

Finally, we simulate Algorithm [9] at each of these upper-bounds. That is, we verify whether all the tran- 
sition deadlines are met while enabling the new-mode tasks at each instant idleA;(J^*''^, tt,?^) (or idlefc(J'j*'^, tt) 
depending on the family of the old-mode scheduler). Obviously, if every transition deadline is met during this 
simulation then it will be met during the actual execution of the application. 

It goes without sajdng that the prior knowledge of the jobs priority assignment allows for establishing tighter 
upper-bounds on the idle-instants, i.e., the upper-bounds idlefc( J, tt, P) are tighter than idlefe(J, tt). Notice that 
it results from these notations that idleni(J, tt) and idleni(J, tTj'P) correspond to the upper-bounds ms{ J^'^ .-k) 
and ms{J^'^, n.T"') introduced in Validity Test[l| respectively. 

Mathematical expressions of these upper-bounds idhkiJ^'^, ^) ^ri*^ idlc/j(J^'''^, tt, V^) on the fc'^ idle-instants 



are defined for both identical and uniform platforms in Sections |6j|9] Algorithm 10 provides details on the 
validity test for AM-MSO, where the upper-bounds idlefc(j^*'=, tt) must be replaced with vi\ek{J^'',7T,T"-) at 
line 9 if the old-mode scheduler is FTP. 



Notice that Algorithm 10 enables new-mode tasks only at the instants idlcfe( J^™'^, tt) (with fc = 1, 2, . . . , m). 



That is, it implicitly considers that every instant at which CPUs become available to the new-mode tasks are as 



late as possible. As a consequence, if all the transition deadlines are met while running Algorithm 10 then all 
these deadlines will be met during every transition phase at run-tim^ Nevertheless, the fact that Algorithm 10 
simulates every idle-instant of every mode transition by its corresponding upper-bound idlefc(J^™, tt) brings 
about the following situation: during the actual execution of the application, there could be some intervals of 
time (during any mode transition) during which the set of currently enabled new-mode tasks benefits from more 
(and /aster) CPUs than during the execution of Algorithm [To] This kind of situation can occur upon identical 
and uniform platforms and for both FJP and FTP schedulers as shown in the following example. 



'Because AlgorithmllOlconsiders every transition between every pair of modes of the application. 



14 



Input: r = {r^, 
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for (all i, j e [1, a;] such that i ^ j) do 

^disabled ^ 

^enabled ^ 

TT^^l ^ 

Sort r^'^^'^'°'^ by non-decreasing order of transition dead- 
lines 

for (k ~ 1; k < m; k++) do 

^avl ^ ^avl ^J 

for (all e r^'"^^) do 
if (I?^(M^) < idkfe(Ji"^ tt)) then 

return false 
end if 

if (sched (tt^vI 5j T-^'^bicd [j{t}})) then 



T T U I j- 



T 

end if 
end for 
end for 
end for 
return true 



enabled 
disabled 



^enabled 
^disabled 



Figure 10: Validity Test for AM-MSO 



Example 5 Let us consider a 5-processors uniform platform vr and a system which is transitioning from mode A'P 
to mode IvP. Other details such as the CPU speeds, the characteristics of the jobs and the job priority assignment 
are not relevant in the scope of this example. Figures\Tl\and\T2\illustrate a situation where during some intervals of 
time the set of currently enabled new-mode tasks benefits from more (and fasterj CPUs than during the execution 
ofAlgorithm\T0\ 
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Figure 11: Illustration of the schedule assumed by the execution of Algorithm 10 In this schedule, new-mode 
tasks are enabled at each instant idle^,, 1 < k < m. 



For sake of clarity, Figure 12 uses the notations idle[. and idlcj. instead o/ idlcfe(J^^'^, tt) and id\ck{J^'^,n), 



respectively. In this latter schedule, there can be less rem-jobs and/or rem-jobs with lower processing times than in 



the schedule of Figure 1 1 since the schedule of Figure 11 is drawn while assuming the critical rem-job set of mode 
KP. This is the reason why the schedule of Figure 12 seems less "loaded" than the one of Figure 11 Due to the 
fact that (i) the validity test provided by Algorithm 10 uses the same function sched(7r, S, r) as protocol AM-MSO 
at run-time and (ii) this function sched(7r, S, r) is independent of the current time, we know that the set of tasks 
enabled at each instant idle), (k — 1,2,..., m) in Figure 12 is the same as the set of tasks enabled at each instant 



idlcj, in Figure [tT] Let us temporarily name this property the "equivalence property". Let T(fc) temporarily denote 
the set of tasks enabled at time idle^, Vfc e [1, m] and suppose that at time id\e^ in Figure\ll\some tasks are enabled 
(i.e., r(3) 7^ (()) and at time idle\ no task is enabled, i.e., r(4) = cf). Thanks to the equivalence property, we know 
that the tasks enabled at time idlcg in Figure 12 are the tasks of t(3) and those enabled at time id\c\ are the tasks 

= idle^, it holds that the tasks enabled at time idkg are the tasks 
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that idle*. 



o/t(4). Since we assumed in Figure 
o/'''(3) U T(4) ~ r(3) (since T(4) = (I)). It follows that in the time interval 



idle^, idle 4 



, only 3 CPUs are available to 
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CPUS+ 

TVr, 
TT4, 



idle! 



(1) 



T(i) UT(2) 



idle^ jdle^ = idle^ 



idle'. 



idle„ 



idle. 



idle. 



time 



idle; 



Figure 12: Illustration of a possible schedule during a transition from mode Af* to mode AP in the actual 
execution of the application. Here, new-mode tasks are enabled at each instant idle^, 1 < fc < m, where 

idlcfe < idle A; . 



the task set r(i) U T(2) U T(3) in Figure\l l\while 4 CPUs are available to this task set in Figure 12 Moreover, during 
this time interval, the additional CPIJ ir^ in Figure 12 is faster (or of equal speed) than every CPU in the subset of 



CPUs {tti, 7r2, TTa} available to r^i) U r(2) U r(3) in Figure 
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Lemma [3] proves that this kind of situation does not jeopardize the schedulability of the application during 
its execution. 

Lemma 3 (See II27II ) Any strongly work-conserving scheduler that is able to schedule a task set t upon a uniform 
platform tt = [si, . . . , Sm] is also able to schedule t upon any uniform platform n* such that (i) tt* D tt and (ii) 

VTTfc e TT* and TTfe ^ TT we have Sk > s,„. 

Proof 1 To obtain the proof it is sufficient to show the lemma for tt* = [si, . . . , Sm,Sm+i] where s„i+i > s,„. The 
proof is made by contradiction. Suppose there exists a task set t that is schedulable by a strongly work-conserving 
scheduler S upon -k, but not upon n* D tt. Consider the schedule upon tt* of a particular set J of jobs issued from 
T that leads to a deadline miss, and let J* be another set of jobs derived from J by reducing the processing time of 
each job Ji by the amount of time Ji executes upon the sub-platform TT*\Tr, i.e., upon TTm+i- Since the scheduler 
is strongly work-conserving, the schedule of J by S upon the CPUs in common with tt is the same as the one that 
would be produced by S for J* upon platform tt. Since a deadline is missed in the schedule of J upon tt*, then a 
deadline is missed also in the schedule of J* upon tt. But since the scheduler is predictable from Lemma^ a deadline 
would be missed on tt even (a fortiori) with the more demanding jobs set J, leading to a contradiction. The lemma 
follows. 

Lemma [s] is proved while considering uniform platforms and strongly work-conserving schedulers but one 
can easily show that it also holds for identical platforms and weakly work-conserving schedulers. 



5 Some basic results for determining validity tests 

5.1 Introduction to the three required key results 

Three key results are required to establish a validity test for SM-MSO and AM-MSO. 

Key Result 1 It must be proved that disabling the old-mode tasks upon any MCR does not jeopardize the schedula- 
bility of the rem-jobs when they continue to be scheduled by the old-mode scheduler That is, it must be guaranteed 
that the absolute deadline d\ of every rem-job ^ is met during any mode transition from every mode AP. 

Key Result 2 The critical rem-job set J^'^ for every mode AP must be determined. Indeed, for every mode transition 



from mode AP to any other mode AP, our validity test (see Algorithm 10) determines the upper-bounds on the idle- 
instants by basing the computations on the corresponding critical rem-job sets J^^ (at line 10). In all cases (i.e., 
identical or uniform platforms and FJP or FTP schedulers), we will provide a proof that the critical rem-job set J^'^ 
of every mode AP is the one that contains one job Ji for each task and such that every job Je g J^'^ has a 
processing time equals to CI, i.e., the WCETofthe task t^. 

Key Result 3 A mathematical expression must be established that provides, for any given set J of jobs and platform 
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1. an upper-bound idlefc( J, n) (1 < k < m) on each idle-instant idlefc( J, tt, X), for every job priority assignment 
X. This concerns FJP schedulers. 

2. an upper-bound idlefc( J, tt, P) (1 < k < m) on each idle-instant id\ek{J:n,V), for a specific job priority 
assignment V. This concerns FTP schedulers. 

Note that the protocol SM-MSO requires only an upper-bound on the makespan, i.e., on the m*'' idle-instant 

idlem( J, tt) and idle„i( J, tt, V). 



5.2 Proof of the first key result 

Lemma [4] proves the first key result introduced above for any uniform platform and strongly v^fork-conserving 
scheduler, as v^fell as any identical platform and v^feakly v^fork-conserving scheduler This result, v^fhich is essential 
to the validity tests of both protocols SM-MSO and AM-MSO, is based on the notion oi predictability introduced 
on pagejT] It has been drawn from [13111 and extended to uniform platforms. 

Lemma 4 Let AP and AP denote two distinct modes of the application. If the application is running in mode 
and a MCR(j) occurs at time tMCR(j) f'lfi" every rem-job meets its deadline during the transition phase while being 
scheduled by the old-mode scheduler ^S^ 

Proof 2 From our first assumption on page^ the set of tasks r' of the mode AP is schedulable by 5* upon tt. When 
the MCR(j) is invoked at time t-^cnij), the transition protocol disables every old-mode task, which is equivalent to 
set the processing time of all their future jobs to zero. Since 5* is predictable (from Lemma^or^depending on the 
scheduler family), the deadline of every rem-job is still met in the produced schedule. The lemma follows. 



5.3 Proof of the second key result 

Corollary[T]proves the second key result introduced above for any uniform platform and strongly v^fork-conserving 
FTP (or FJP) scheduler, as well as any identical platform and weakly work-conserving FTP (or FJP) scheduler 
It has been drawn from the following Lemma [s] 

Lemma 5 Let tt be any uniform multiprocessor platforms (including identical platforms) and let J and J' be 
any fixed set of n synchronous jobs such that J — { Ji, J2, . . . , Jn} of processing times ci,c2,...,c„ and J' — 
{J[, J2, . . . , J'n} of processing times c[,C2, ■ ■ ■ , c'j. For any job priority assignment V, if there exists a bijective 
function between J and J' such that every job £ J' is mapped to exactly one job Jr € J and such that < Cr, 
then the fc*^ idle-instant idlefe( J, tt, V) (ik e [1, m]) in the schedule of J upon tt is not lower than the fc"^ idle-instant 
idlefc( J', TT, V) in the schedule of J', i.e., it holds Vfc e [1, m] that 

idlCfe(J',7r,7') <idlefe(J,^,7') 

Proof 3 The proof is a consequence of the predictability of work-conserving schedulers (including both weakly and 
strongly work-conserving schedulers) . Let S and S' denote the schedule of J and J' upon tt with V, respectively. We 
denote by comp^ and comp^ the completion time of any job J^. in S and J'^ in S', respectively. It follows from the 
fact that < Cr (Vr G [1, n]) and from the predictability of the considered schedulers (see Lemma^or^depending 
on the scheduler family) that Vr e [1, n]: 

comp'. < comp^ (3) 
The proof is made by contradiction. Suppose that there exists £ £ [l,m] such that 

id\et,{J,Tr,V) < idle^ ( J', tt, T^) 



Figures 13 and 14 illustrate an example of schedules S and S' on a 5-processors uniform platform, respectively, 
where idlc3(J,7r,7') < idlc3( J', tt, T'). 

Since the platform is uniform in these examples, the scheduler is strongly work-conserving and both schedules S 



and S' form a staircase. In both Figures\T3\and 14 we voluntarily omit the detaib about the CPU speeds, the jobs 



characteristics, etc. since they are useless in the scope of these examples. 



Similarly, Figures 15 and 16 illustrate an example of schedules S and S' on a 5-processors identical p?at/orm, 
respectively, where idle3( J, tt, T') < idle3(J', tTjT'). Since the platform is identical in these examples, the scheduler 
is assumed to be weakly work-conserving. Furthermore, note that in both examples no job is released after time 0. 

By definition of the idle-instants, the schedule of any set J of jobs upon any uniform or identical multiprocessor 
platform is such that Vfc e [1, m]: 

• the idle-instant idlefe(J', tt, V) corresponds to the completion time of a job. 
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Figure 13: An example of schedule S upon a 5-processors uniform platform. The idle-instants id\ek{J,TT,V) are 
denoted by idlcfe for sake of clarity. 
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Figure 14: An example of schedule S" upon the same 5-processors uniform platform. Also for sake of clarity, 
the idle-instants idle^ ( J, tt, V) and idlcfe (J', n, V) are denoted by idlefc and idlej,., respectively. In this figure, we 
have by contradiction idles < idleg. 
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Figure 15: An example of schedule S upon a 5-processors identical platform. The idle-instants idlcfe( J, tt, V) are 
denoted by idle/c for sake of clarity. 
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Figure 16: An example of schedule S' upon the same 5-processors identical platform. Also for sake of clarity, 
the idle-instants idlc^, ( J, tt, V) and idlcfc (J', tt, V) are denoted by idlcfe and idlcj,, respectively. In this figure, we 
have by contradiction idles < idleg. 



• there is no waiting job at time idlefe(J', tt, V) and, 

• there are at most (m — k) running jobs at time idlefc (J, tt, V). "At most" since there can exist some r > k such 
that idleri J,TT,r) = idlefc ( J', 71,75). 
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Since every idle-instant corresponds to the completion of a job, this implies that within the time interval 
[id\ei{J,7r,V),id\ei{J' ,n,V)] there are at most (m — £) running jobs in S while there are at least {m — i + \) 
running jobs in S'. Therefore, within [idlei{J,T:,V),idlee{J' ,7r,V)], at least one job (say Jr) is already completed 
in S while J'^. is still running in S'. The fact that J'^ completes later in S' than Jr in S leads to a direct contra- 
diction of Inequality^ As we can see in Figures\T^and 16 three jobs are running in S" during the time interval 



[idle3( J, TT, V), idle3( J', tt, V)] while only two jobs are running in S, meaning that there is one job which is completed 
in S and still running in S'. The lemma follows. 

Corollary 1 For any uniform multiprocessor platforms tt and for any transition of the system from mode AP to 
mode M^, let J^"^ denote any set of rem-jobs issued from the old-mode tasks and let J^'^ be the set of rem-jobs 
that contains one job Je for each task and such that every job Jg e J^'^ has a processing time equals to C|. 
The k^^ idle-instants idlefe(J^^'^, tt) (V/c S [1,toP in the schedule of J^'^ is never lower than the fc"^ idle-instant 
idlefe( J^"y, tt) in the schedule of J'^"^ i.e., it holds Vfc e [1, m] that 

idlefc(J^"^^) <idlefe(Ji*^7^) 

Proof 4 The proof is a consequence ofLemma^ Let c*^ and c^"^ denote the processing time of job J.^ in J^'^ and 
jany^ fespectivefy. By definition, J^'^ contains one job of processing time C\.for each task G t*, i.e., it holds 
Vr; e t' that 

and thus we know by definition of J''"^ that V G J''"^, 

In addition, we know that there could be some jobs Je e J^'^ such that Jg ^ J™^ (since J™^ does not necessarily 
contain one job for each old-mode task). For each such job Jg we add a fake job J'^ in J^'^^ with c™^ = 0. It results 
from this operation that the number of jobs in both J^'^ and J'*"^ are the same (we denote this number by n) and 
there is a bijective function between J^'^ and J'*"'' such that every job Jr G J^'^ is mapped to by exactly one job 
Jr e J^'^^ and such that cj^"^ < c^'^. Thanks to this bijection, we know from Lemma^that Vr e [1, m] we have 

idle,(J""y,^) < idle,(J^"'^7^) 

and the corollary follows. 

By definition, for every mode transition from any mode AI^ upon tt, each id\ek{J.^'^, vr) is an upper-bound 
on the fc*'' idle-instant in the schedule of J^'^ (this also holds for each upper-bound idlci:(J^""^, tt, V) if the job 
priority assignment V is known beforehand). Thanks to Corollary [T] we are now aware that each upper-bound 
idlefc(>y^^'^, tt) (and id\ek{J^'^, tt, V)) is also an upper-bound on the k*-'^ idle-instant in the schedule of any other 
set of rem-jobs issued from the old-mode tasks (i.e., the tasks of t*). That is, for every mode transition from 
any mode AP we have V/c e [l,m]: idlcfe ( Ji*^ tt) > idlefc(J^*^ tt) > idlefc^J''"^, tt) and idlefc(Ji*'=, tt, 7^) > 
idlefc(J^^'^, TT,?^) > idlek{J^^^ ,Tr,V), where J™^ denotes any set of rem-jobs issued from the tasks of t\ As a 
result, the instants idlek{J^'^ ,n) (and idleA;( J^^'^, tt, V)), with k — 1,2, ... ,m, can be considered as the largest 
instants at which new-mode tasks are enabled during every transition from mode Af ' and thus, these instants 



can be used in our validity test given by Algorithm 10 



5.4 Organization for the third key result 

The third key result consists in determining a mathematical expression for each upper-bound id\ek{J,n) (or 
idlefe(J, TTjT') depending on the scheduler family, i.e., FJP or FTP), for all 1 < fc < m. Depending on the tj^e 
of the platform (uniform or identical) and on the scheduler family (FJP or FTP), we distinguish between four 
different cases that are studied in turn in the following four sections. More precisely: 

Section |6] addresses the identical and FJP case. 
t> Section [t] addresses the identical and FTP case. 
Section [s] addresses the uniform and FJP case. 
Section [9] addresses the uniform and FTP case. 

Recall that the protocol SM-MSO requires only an upper-bound on the makespan, i.e., on the m"^ idle- 
instant. The organization for the third key result is as follows. 
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6 Identical platforms and FJP schedulers 



This section is organized as follows. First, Section 6.1 determines an upper-bound idlefe(J, vr) on the earliest 



time-instant where at least k CPUs are idle and derives an upper-bound ms( J, tt) on the maximum makespan. 



Then, Section 6.2 shows that this upper-bound ms(J, vr) is 2-competitive, with the interpretation that nis(J, tt) 



is at most twice the exact value of the maximum makespan. Finally, Section 6.3 establishes a sufficient validity 
test for protocols SM-MSO and AM-MSO. 



6.1 Upper-bounds idlefc( J, tt) on the idle-instants 

Throughout this section, J refers to any set of n jobs. For sake of clarity, we will use the notation idlcfc instead of 
idlefe(J, tt) and similarly, we will use the notation idlcfc to denote the exact value of the k*^^ idle-instant. Before 
introducing the computation of these upper-bounds idkfc, 1 < /c < m, let us introduce the following result taken 
from I13T1I . 

Lemma 6 (See II31II ) Suppose that J is sorted by non-decreasing job processing times, i.e., ci < C2 < ■ ■ ■ < c„. 
Then, whatever the job priority assignment we have Vj, fee [1, ™] such that j < k: 

idXej > idkfc - Cn-m+k 

Based on this Lemma |6j the following result was proved in our previous work llSTII . 

Lemma 7 (See 113111 ) Suppose that J is sorted by non-decreasing job processing times, i.e., ci < C2 < • • • < c„. 
Then, whatever the job priority assignment, an upper-bound idle^ on the idle-instant idlck, I < k < m, is given by 
Ck ifn — mor by 



En ^— ^^+m — fc + 1 ^— \z-t-m — fc + 1 

max < — ^ '—^ + , , , } (4) 

=0 m m — fc -f 1 



Otherwise (n > m). 



Holding this result, we improve here this previous analysis by (i) successfully establishing another upper- 
bound idlefc( J, tt) on each idle-instant idlefc( J, tt) and (ii) proving that these alternative upper-bounds are always 
tighter than those proposed in Lemma [7] In short, we complete our previous work HSlll as follows. 

t> Lemma [s] shows that Expression [4] of idle^, is always maximal for i = n — m -f fc — 1. 
Lemma ^proposes another upper-bound idlefe(J, tt) on each idle-instant idle^. 



> Lemma [10| shows that these alternative upper-bounds idlek{J, tt), Vfc e [1, m], are never larger than those 
provided by Expression [4] 

t> Finally, based on these alternative upper-bounds. Corollary |2] derives an upper-bound on the makespan. 
Lemma 8 If n> m, Expression^is maximal for i ^ n — m + k — 1. 

Proof 5 This result is presented in Lemma 2.10 in 128] . Due to the space limitation and because the proof is simply 
based on algebra, we do not repeat it here. 

Thanks to Lemma [sj Expression [4] can be rewritten as follows: idle^ =^ Cfe if n = m or 

V" r - V" r ■ V" r ■ 

idlefc = — 1 , 7, (5) 

m TO — K -h 1 

Otherwise (n > to). 



Lemma 9 Suppose that J is sorted by non-decreasing job processing times, i.e., ci < C2 < • • • < c„. Then, whatever 

the job priori 
n = morby 



the job priority assignment, an upper-bound idlcj. on the idle-instant idlcfc, 1 < fc < to, is given by idle^ =^ if 



idk, drf Etl Q + (fc - 1) ■ Cn-m+k 



Otherwise (n> m). 



Proof 6 The case where n = mis obvious. Otherwise, the proof is made by contradiction. Suppose that there exists 
fc e [1, to] such that idle^ > idle^. The following properties hold: 
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• Prop, (a): Vj > k: idlej > idlefe (by definition of the idle-instants). 

• Prop, (b): Vj < k: idlcj > idle^ — Cn-m+k (fiom Lemma^. 
The proof starts with this obvious equality: 

rn k—1 m 

idlej — ^ idhj + idle^ + ^ idle^ 

j = l j = l j=k + l 

Then, applying properties (a) and (b) to the right-hand side yields 

m k— 1 m 

^idle, > ^(idkfe ) + idlcfe + ^ idlefe 

j=l j=l ]=k+l 

> (fc - l)(idlefc - c„-m+k) + idle*: 
+ {m — k) ■ idlcfe 

> m • idlefc - (fc - 1) • Cn-m+k 

Since by hypothesis idle^ > idlcfc, replacing idle^ with idlcfe in the above inequality leads to 

m 

idkj > m • idlcfc - (fc - 1) • Cn-m+k 

^ ^ I X/i=l + (fc ~ 1) • C„_„i+fe 



> 



m 

"(fc 1) ' Cn— m+fe 



r/iis Zeads to a contradiction since it obviously holds by definition of the idle-instants that X^JLi i^l^^i — ^"=1 
r/ie lemma follows. 



Lemma 10 The upper-bounds idlc^ Cwit/i fc = 1,2, ... ,m) provided by Expression ^are never larger than those 
provided by Expression^ 

Proof 7 The proof is made by contradiction. Let fc be any integer in [l,m]. Let idle^''^ and idle)^°^ denote the 

upper-bound provided by Expressions^and^ respectively, and suppose that idle'^°" > idle)?'"^. from Expressions [5] 
and [6] we get 

= l '^j + (fc ~ 1) ' C„_m+fe 

m 

V c - T" c V" c- 

^ jL^j — l J ^j—n — m+k J ^ j—n—ra+k 3 

m m — fc + 1 

By multiplying both sides by m ■ {m — k + 1) we get 



(m-k + l)- {J2c, + {k-l) 



^71— m+A; 



> (m - fc + 1) • I ^ Cj - ^ Cj j + m ^ < 



Thus, 



(m - fc + 1) • (fc - 1) • c„_™+fc > (fc - 1) • ^ Cj 

j—n — m-\-k 

Ifk~l then we obviously get > and the lemma follows. Otherwise, if k > 1 then dividing both sides by {k — 1) 
yields 

n 

(m - fc + 1) • Cn-m+k > ^ Cj 
j—n—m-\-k 

In this case, in the right-hand side of the above inequality, there are m — fc + 1 terms that are not lower than Cn-m+k 
each. This therefore leads to a contradiction since ci < C2 < • • • < c„. The lemma follows. 
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The following corollary derives an upper-bound on the makespan from idle„i provided by Expression [6j 



Corollary 2 Suppose that J is sorted by non-decreasing job processing times, i.e., ci < C2 < ■ ■ ■ < c„. Then, 

whatever the job priority assignment, an upper-bound ms'^°"*( J, tt) on the makespan is given by nis"*™*( J, tt) =^ c„ 
ifn^m, or by 

^r^n~ 1 

m 

otherwise. 

Proof 8 Since the makespan corresponds to the m*^ idle-instant, an upper-bound on the makespan is given by 
idlc,„. Therefore, the proof is obtained by simply replacing k with m in Expression p] 



6.2 Accuracy of the upper-bound ms"^'^''*( J, vr) 

In this section, Lemma 11 proves that the upper-bound nTs"^''"*( J, tt) is 2-competitive, according to the following 



definition. 

Definition 15 (a-competitive) Any upper-bound is said to be a-competitive if it provides at most a times the 
exact value of the approximated parameter 

This is achieved under the assumption that during any mode transition all the rem-jobs execute for their 
WCET. Without this assumption, the minimum makespan that could be produced is always since it can always 
be the case that no old-mode task has an active job when the mode change is requested. For instance in Figurejs] 
the makespan would be zero if the MCR(j) was released at time 110. However, in order to guarantee that our 
approach always provides an upper-bound on the makespan we have to consider the worst-case scenario in 
which every old-mode task releases a job exactly upon the mode change request and all these jobs executes for 
their WCET during the transition. 

Lemma 11 For any set J of jobs sorted by non-decreasing job processing time and for any identical multiprocessor 
platform tt composed ofm CPUs, the upper-bound ms"^™*(J, tt) is 2-competitive. 

Proof 9 Recall from Expression^that, 

, , f c„ if {n < m) 

— ^_ ^ otherwise 

Let ms(J, m) denote the exact makespan for the set J of jobs and the m identical CPUs. Since we do not have any 
mathematical expression for determining this exact makespan ms( J, m), our analysis is performed while considering 
a lower-bound ms"*°"'( J, m) on the makespan rather than its exact value, i.e., a is determined in such a manner 
that 

ms'^™*(J,7r) 
nis''i™*(J, m) 

where 



< a 




if n < m 
{cn, •^'='''' } ifn>m 



The case where n < m obviously leads to q = 1 since both ms"^™*(J, tt) and nis"^°"'( J, tt) return a makespan ofcn. 
Otherwise (if n > m) the "max" operator in the definition o/ms"*™*(J, m) leads to two different cases. 
Case I: If Cn> then we get 



ms''^°"HJ. m) ~ c„ 

^ m 



and since in this case we have Cn > ^'^^ it holds that 

ms''^™'(J,7r) 



< 



ins( J, m) c„ 
< 2 
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Case 2: //c„ < then 



and since in this case we have Cn < 



ms 



■idcnt 



(J,^) 



ms 



idcnt 



(J,m) 



< 



, it holds that 



ms 



dent 



(J,^) 



ms( J, m) 



< — 

< 2 



r/ie lemma follows. 



It holds from Lemma 11 that, for any set J of jobs and any identical platform composed of m CPUs, 
the upper-bound on the maximum makespan provided by nTs"^''"*( J, tt) is at most twice the exact value of the 
maximum makespan. Additionally we can show that in some particular cases as the one provided in the following 
example, the upper-bounds idlcfc( J, tt) (Vfc G [1, m]) defined on page 
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are exact. 



Example 6 Let us consider the set of 12 jobs with characteristics given in Table^to be scheduled on a 3-processors 
identical platform. 



Cl 


C2 


C3 


C4 


C5 


C6 


1 


1 


1 


1 


1 


1 


C7 


C8 


cg 


ClO 


Cll 


Cl2 


3 


3 


6 


6 


9 


12 



Table 3: Processing times of the 12 jobs in J. 



For this set of jobs, 



• the upper-bound idlci = 15 is reached with the job priority assignment Jy > Jg > Jio > J12 > Jii > Jg > 

Ji > J2 > J3 > Ji > J5 > Je- 

• the upper-bound idlc2 = 18 is reached with the job priority assignment Jio > Jg > Ji > J2 > 0/^3 > J4 > 
J5 > Je > J12 > J7 > Js > Jii- 

• the upper-bound idles = 23 is reached with the job priority assignment J7 > Jn > Jio > Ji > J2 > Jg > 

Js > J3 > J5 > J4 > Je > Ji2. 

Due to t/ie space limitation, we did not drew the schedules corresponding to these priority assignments. 
6.3 Validity tests for SM-MSO and AM-MSO 

From Corollaries [1] and [2] the sufficient validity test given by Test[T]on page|9]can be rewritten as follows. 

Validity Test 2 (SM-MSO, Identical and FJP) For any multi-mode real-time application t and any identical plat- 
form TT composed ofm CPUs, the protocol SM-MSO is valid provided that, for every mode M\ 



jj^idcnt^^wc^ tt) < min <^ min • 

j^i I k= ' 



where ms"^''"*( J^^'^, tt) is defined as in Expression^and J^'^ is defined as follows: 

each job e J^'^ has a processing time equal to the WCET Cl of task 
t> J^'^ is sorted by non-decreasing processing time. 

Concerning the protocol AM-MSO, the upper-bounds id\eh{J^'^,TT) (for all 1 < A; < to) defined as in 
Lemma [9] can be used at line 10 of the validity algorithm given by Algorithm 10 (on page 15 ). 
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7 Identical platforms and FTP schedulers 



This section is organized as follows. First, Section 7.1 determines an upper-bound idlej,(J, tt, T') on each idle- 
instant idlefc ( J, TT, V) for any given job prio rity assignment V and derives an upper-bound ms"^''"* ( J, tt, 7^) on the 

shows that this upper-bound ms"^°"'( J, tt) is 1 -competitive, with the 



7.2 



maximum makespan. Then, Section 

interpretation that ms"^°"'(J, tt) corresponds to the exact value of the maximum makespan. Finally, Section 
establishes a sufficient validity test for the protocols SM-MSO and AM-MSO. 



7.3 



7.1 Upper-bounds idlefc (J, vr, P) on the idle-instants 

As introduced earlier, this section focuses on determining a mathematical expression for the upper-bounds 
idlefc (J, TT, V) where J refers to any set of n jobs, tt denotes any identical multiprocessor platform composed of 
m CPUs and P is a specific given job priority assignment. Indeed, for a given FTP scheduler the priority of every 
task (and thus of every job) is know beforehand. This prior knowledge allows us to determine tighter upper- 
bounds than those proposed in the previous section. Once again, for sake of clarity, we will use the notations 
idlefc and idlefc instead of idlefc (J, tt, P) and idlefc (J, tt, T'), respectively. 

For any transition from a given mode AP to any other mode AP , the knowledge of the critical rem-job set 
J^'^ and the fact that the job priority assignment is known beforehand allow us to compute the exact maximum 
idle-instants idlefc — exact in the sense that they are actually reached if every job executes for its WCET — simply 
by drawing the schedule of J^'^ and by measuring the idle-instants idlcfc in that schedule. Indeed, from Corol- 
lary [T] (on page 191, each idle-instant idlefc( J^*'^, tt, T') is an upper-bound on the idle-instant idlcfc( J, tt, P) de- 
rived from the schedule of any other set J of rem-jobs. Before expressing these exact maximum idle-instants, 
let us introduce the following definition. 

Definition 16 (Processed work Workj) Let vr denote any identical multiprocessor platform and let S he any 
global, weakly work-conserving and FTP scheduler Let J = { Ji, J2, . . . , J„} denote any set of n jobs sorted by 
decreasing S-priority, i.e., Ji >s J2 >s ■ ■ ■ >s Jn and let denote the schedule by S of the i highest priority 
jobs of J upon TT. The processed work Work). (1 < k < m and < i < n) denotes the amount of processing time 
executed on CPU nk in S\ 

In order to familiarize the reader with this notation Workfc, we provide the following example. 

Example 7 Let us consider the set J of 7 jobs with characteristics given in Table^to be scheduled on a 4-processors 
identical platform, following the priority assignment: Ji > J2 > • • • > J7. 



Cl 


C2 


C3 


C4 


C5 


C6 


C7 


7 


2 


5 


16 


6 


5 


5 



Table 4: Processing times of the 7 jobs in J. 
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Figure 17: Illustration of the notion of processed work Work^ 



Figure 1 7 illustrates the schedule of J upon the 4 CPUs. In this schedule, we have Workg = 8 because, in the 



schedule S" of the 5 highest priority jobs Ji, J2, J3, J4, J5, the amount of processing time units executed on 7:3 is 
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C2 + C5 = 8. Similarly, Work| = 7, Workg = 2, Workj = 5 and WorkJ = because, in the schedule of 
jobs Ji, J2, J3, we can see that 7 processing time units are executed on 7:4 (i.e., job Ji), 2 processing time units are 
executed on tt^ (i.e., job J2), 5 processing time units are executed on 1:2 (i-S-, job J3) and no processing time unit is 
executed on tti. Notice that Work° = Vfc = 1, 2, . . . , m. 



Lemma 1 1 2| provides the exact values of Work^ (Vi e [l,n] and Vfc e [1,^]) when each job executes for its 
WCET. Then, Corollary [s] derives the exact maximum idle-instants idle^: 1 < fc < m, for the scheduling of any 
set J of n jobs upon any m-processors identical platform. 

Lemma 12 Let tt denote any identical multiprocessors platform composed ofm CPUs. Let S be any global, weakly 
work-conserving and FTP scheduler and let J be any set of n jobs sorted by decreasing S-priority, i.e., Ji >s J2 >s 
■ ■ ■ >s Jn- It holds Vfc e [1, m] and Vi e [1, n] that 

■„r ,i Work'.-^+Ci if = max <^ argminj Worker n I 

Work'fe = [<G[l,ml^ ' '} (8) 

[Work^~^ otherwise 

where Work^ = Vfc by definition of the processed work. 

Proof 10 The proof directly follows from the definition o/Work^ Vi,fc and from the second condition of our def- 
inition of a weakly work-conserving scheduler (see Definition^ page^. Indeed, whenever a subset P of several 
CPUs idle (or complete a job) at the same time, S dispatches the waiting job (if any) with the highest priority to the 
CPU of P with the highest index (this is the reason for the condition "if k is the highest value of £ that minimizes 
Work^-i"J. 

Corollary 3 An upper-bound idle^, 1 < k < m,is given by the fc"^ element of the vector {Work", Workj , . . . , WorkJ^} 
sorted by non-decreasing order 

Proof 11 The proof directly follows from the definition of the processed work Work)!, Vfc e 

Corollary 4 The maximum makespan ms"*™*(J, tTj'P) is given by idlem^ where idhm is determined as in Corol- 
lary^ 



7.2 Accuracy of the upper-bound ms"^'^''*( J, tt, V) 

In this section we prove that the upper-bound ms"^™'(J, tt,?^) is 1-competitive, i.e., exact — exact in the sense 
that it can actually be reached if every job executes for its WCET. Again, this is achieved under the assumption 
that during any mode transition all the rem-jobs execute for their WCET as we have to consider the worst-case 
scenario in which every old-mode task releases a job exactly upon the mode change request and all these jobs 
executes for their WCET during the transition. 

For any transition from a given mode Af * to any other mode M\ the knowledge of the critical rem-job set 
J.^'^ and the fact that we proceed by simulation allow us to compute the exact maximum idle-instants simply 
by drawing the schedule of J^'^ following V and by measuring the idle-instants in this schedule. Using this 
approach, the measured upper-bound nTs"^''"*(J, tTjT') is nothing else but 1-competitive. 



7.3 Validity tests for SM-MSO and AM-MSO 

From Corollary[4j the sufficient validity test given by Test[T](on page|9]) can be rewritten as follows. 

Validity Test 3 (SM-MSO, identical and FTP) For any multi-mode real-time application t and any identical plat- 
form TT composed of m CPUs, the protocol SM-MSO is valid provided that, for every mode AP, 

j^idont^^wc 



iJr, < min \ min {vi (AP)} 

I k=i y. J 



where ms"^''"' (J^r'^, ^r) is defined as in Corollary^ V is obtained from the old-mode scheduler and J^'^ is defined 
as follows: 

i> each job e J^'^ has a processing time equal to the WCET CI of task tI 
t> J^'^ is sorted by decreasing S^-priority. 

Concerning the protocol AM-MSO, the upper-bounds idlefc(Ji*'^, tt, T'*) (for all 1 < fc < m) determined in 
Corollary [3] can be used at line 10 of the validity algorithm given by Algorithm 10 on page 15 1. 
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8 Uniform platforms and FJP schedulers 



8.1 Some useful observations 

In this section, we show that the maximum makespan determination problem is highly counter-intuitive upon 
uniform platforms and the methods for solving this problem cannot be straightforwardly extended from those 
proposed for identical multiprocessor platforms. First, recall that the schedulers are assumed to be strongly 
work-conserving here since we focus on uniform platforms. 

Observation 2 For a given set of jobs, an intuitive idea for maximizing the makespan upon any m-processor 
uniform platform is to execute, at any time, the longest job upon the slovi/est CPU, i.e., the shorter the computation 
requirement of a job, the higher its priority. We name this priority assignment "Shortest Job First" (SJF). However, 
we can show by using the following example that this intuitive idea is erroneous, as SJF does not lead to the 
maximum makespan. 

Example 8 Let us consider the set J of i jobs Ji, J2, J3, Ji of respective processing times 4, 4, 16 and 22, and 
suppose that they are scheduled on the 2-processors uniform platform tx = [1,2]. The priority assignment SJF (i.e., 
Ji > J2 > J3 > J4) provides a makespan of 17.75 whereas the priority assignment J3 > Ji > J2 > J4 leads to 
a makespan of 19. Notice that the problem of determining in a polynomial time (i.e., without trying every priority 
assignment) a priority assignment leading to the maximum makespan remains an open question and is out of the 
scope of this study. 

Observation 3 Another intuitive idea is to naively extend to uniform platforms the result (replicated below) of 
Corollary^on page 22 i.e., for any identical platform tt composed of m CPUs, an upper-bound on the makespan 



is given by 

{Cn if [n = m) 

, (9) 
— h c„ otherwise 
m 

where Ci is assumed to be such that Ci > Ci_i Vi e [2, n]. 

Upon identical platforms there is a sense in distinguishing the case n = m from the case n > m, because 
the rem-jobs never migrate between CPUs during mode transitions. Therefore, in the particular case where 
n = m, the maximum makespan does not depend on the job priority assignment and can be determined exactly 
by nis"^™*( J, tt) = c„. In contrast, we can easily show that this property does not hold upon uniform platforms. 
That is, the maximum makespan in the case n — m is not independent from the job priority assignment upon 
uniform platforms. This is shown through the following example. 

Example 9 Consider the uniform platform tt = [1,2] and the two jobs Ji, J2 of processing time 4 and 6, respectively. 
If Ji > J2 then Ji completes on 1x2 at time 2 — time during which J2 executes 2 execution units on tti — and J2 
completes on 1x2 at time 4, thus leading to a makespan of 4. On the other hand, if J2 > Ji then J2 completes on 
■K2 at time 3 — time during which Ji executes 3 execution units on vri — and Ji completes on 1x2 at time 3.5, thus 
leading to a makespan of 3.5. As a result, the maximum makespan in the case n ^ m depends on the job priority 
assignment on uniform platforms and the case n — m can no longer be distinguished from the case m < n. 

From the previous example, naively extending Expression [9] to uniform platforms yields the following "1- 
piece" expressiorp") 

mbg \J,TX = — 1 (.lOj 

s(l) s,„ 

Unfortunately, we show in the following example that this extension does not provide an upper-bound on 
the maximum makespan. 

Example 10 Let us consider the set J of 3 jobs Ji, J2, J3 of respective processing times 50, 80 and 99, and sup- 
pose that they are scheduled on the 3-processors uniform platform tx — [1,2, 10]. The maximum makespan is 20, 
reached using the job priority assignment Ji > J2 > J3 (see Figure\T8^. On the other hand. Expression 



yields 
This 



msg"'^( J, tt) = + |2 — x9 9_ xfiis approximation made by Expression 10 is illustrated in Figure 

simple example is much more important than what it seems to be at first blush and we will deeply examine its 
impacts in Section 8.4 (page\30]^. 



"'recallthats{l) ='X;™iSi 
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Figure 18: This picture depicts a priority assignment leading to a makespan of 20. The speed of each CPU is 
indicated into brackets next to its label. The numbers next to each job name Ji is the amount of work processed 
by Ji upon the allocated CPU. For instance, job Ji executes 50 execution units from time to 5 on CPU tts, 
leading to its label Ji(50). 
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Figure 19: Approximation error made by Expression [To] 



8.2 Upper-bounds idlefc( J, vr) on the idle-instants 

Once more but this time for any uniform platform tt, we focus on determining a mathematical expression that 
provides an upper-bound idlefc( J, tt) on the fc"^ idle-instant, V/c e [1, m]. For sake of clarity, the following two 
lemmas use the notations idle^ instead of idlefc( J, tt) and similarly, the notation idlcfc will be used to denote the 
exact value of the fc'^ idle-instant. First, Lemma 13 determines a lower-hound idle ^, on each idle-instant idle^, 

1 < fc < m. Then, Lemma 14 determines an upper-hound idlet on each idle-instant idle^. Finally, Corollary [s] 
derives an upper-bound on the maximum makespan (recall that the maximum makespan is simply given by 
idle„). 

Lemma 13 (See [27j) Let tt = [si, S2, . . . , s,,,.] he any m-processors uniform platform such that Si > Sj_i Vz, 

2 < i < m. Let J = {Ji, J2, . . . , J„} he any set of n johs of respective processing times ci, C2, . . . , c„ such that 
ci < C2 < ■ ■ ■ < c„. Let S he the schedule of J upon n following any glohal, strongly work-conserving and FJP 
scheduler A lower hound idle^ on each idle-instant idlcfc (1 < k < m) in S is given hy 



idlej. 



dcf 



(11) 



Proof 12 According to the definition of the idle-instants, at most (m — fc) johs are not completed at time idle^, 
meaning that at least {n — m + k) johs are already completed. Let J'*"^ he any suhset of J composed of r johs, where 
{n — m + k) < r < n. Ohviously, a lower hound t on the instant at which the r johs of J^"^ are completed is given 

by 

^ def X/Jjgjany '^i 



s{l) 

and since c\ < C2 < ■ ■ ■ < Cn, t is minimal if (i) the numher of johs in J™^ is low as possihle, i.e., r = n 
m + k, and (ii) the processing time of each joh of J^"^ is low as possihle. As a result, t is minimum for J^'^^ 
{ Ji, J2, . . . , Jn~m+k} and thenyields a lower-hound for idle ^. 
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Lemma 14 (See [27|) Using the same notations as in the previous lemma, an upper-bound idlc^ on each idle- 
instant idlefe (1 < k < m) in S is given by 



i=i c^ - L»=i iQle, 



idlefc = m (12) 



where s{k) =^ X^i" fc (^^^ defined in Expression^ page^. 



Proof 13 From the "staircase" property derived from the definition of a strongly vi/ork-conserving scheduler on 
uniform platform (see page^^or details) and from the fact that all the jobs are assumed to be synchronous at time 
0, we fcnow that CPU -Kj becomes idle at time idhj, Vj = 1,2,..., m. Let Wj (1 < j < m) denotes the amount of 

work executed on CPU vTj within [0, idle^], i.e., wj =^ idlcj • sj. The proof is made by contradiction. Let £ be any 
integer in [1, m] and suppose that idlee > idle^. By definition ofwj, we know that 



3 = 1 



and from the definition ofwj we know that 



3 = 1 3 = 1 

l-l m 

3 = 1 j=e 

By definition of the idle-instants, it holds Vj > £ that idlc^ > idle^. Therefore, replacing "idlej" with "idle^" in the 
second term of the right-hand side of the above equality yields 

m £—1 m 

j=i j=i j=e 

i-l m 

> ^{idloj ■ Sj) + idlee -^Sj 

3=1 3=i 

By hypothesis we have idlc^ > idlc^. Therefore, replacing idlc^ with idlee in the right-hand side of the above 
inequality yields 

m £—1 m 

j=i j=i j^e 

E) 1 Cj — > . , idle; • Si \ ^ 
(idle, • s,) + — ' • E 

l-l n e-1 

j = l i = l ! = 1 

> Y^^ + Y. ((idle, - idle^ ) • s,) 



Since from Lemma 13 it holds that idle , < idlc^ Vi = 1, 2, . . . , to, it holds that 

£-1 

((idlej - idle^) • Sj) > 

3 = 1 

and thus 

m n 

Y2w3 > I]c, 

j=l i=l 



leading to a contradiction with Equality 13 The lemma follows. 
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Corollary 5 (See [27| ) Whatever the job priority assignment, an upper-bound ms""'^(J, tt) on the makespan is 
given by 

/ n m— 1 \ 

if / T _^ def 1 



Ymr'iJ, ^) = — • ^ Q - ^ idle, • (14) 

Proof 14 Since the makespan corresponds to the idle-instant idle,„, an upper-bound on the makespan is given by 
idle™. Therefore, the proof is obtained by simply replacing k with m in Expression 12. 



8.3 Accuracy of the upper-bound ms^"'^( J, vr) 

In this section we prove that the upper-bound ms""'^(J, tt) is ^^-competitive, v^rith the interpretation that the 

value returned by nTs"'"^( J, tt) is at most times the exact value of the maximum makespan for any given set 
J of jobs and uniform platform tt. Once again, this is achieved under the assumption that during any mode 
transition all the rem-jobs execute for their WCET as v^re have to consider the v^forst-case scenario in which every 
old-mode task releases a job exactly upon the mode change request and all these jobs executes for their WCET 
during the transition. 

Lemma 15 For any set J of jobs sorted by non-decreasing job processing time and any uniform platform vr = 
[si, S2, • • ■ , Sm] with Si > Si^i Vi, ms""'*(J, tt) is ai{Tr)-competitive, where ai(7r) =^ ^p^. 



Proof 15 Recall from Expression 14 that 



nisr'^(J,7r) 



En 



fc=i [1^1=1 ' 

Sm ■ s(l) 



Let ms( J, tt) denote the exact makespan for any given set J of jobs and any uniform platform tt. Since we do not 
have any mathematical expression for determining this exact makespan ms( J, tt), our analysis of ai (tt) is performed 
while considering a lower-bound ms( J, tt) on the makespan rather than its exact value, i.e., ai{n) is determined in 
such a manner that 

nTsr"(J,7r) 



ms( J, tt) 



< ai(7r) 



Obviously, we know that nis(J, tt) > 
makespan. This yields 



O-^d this implies that nis(J, tt) =^ ^s{i)'^' lower-bound on the 



and thus. 



msrf(J,7r) 



< 



f(J,7r) 



ms 



unif / 



ms(J, tt) ms(J, tt) 



J,7r) 



ms( J, tt) 



< 



s(l) 



/ n m — 1/n — m + fe \\ 



En 



s(l) 



Sm ■ S(l) 
.(1) 



En 



En 



(15) 



(16) 



Notice the important loss of accuracy that this inequality underwent when we ignored the term 



while passing from Inequality 15 to Inequality 16 The lemma follows. 
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Figure 20: Example of schedule in which the makespan is larger than that returned by msQ°'^( J, tt). 



8.4 Another analysis of the maximum makespan 



In Example 10 on pa ge |26| we have showed that the naive extension of ms"^°"'( J, tt) (given by mSo'"^( J, tt) in 
Expression |10[ page |26|) does not provide an upper-bound on the maximum makespan considering uniform 
platforms. Essentially, in addition to refute the fact that nTso'"^( J, tt) provides an upper-bound on the maximum 
makespan, this example also refutes the main concept behind the expression o/ ms"^°"'(J, tt). Indeed, in the 

expression of ms *( J, tt), it can be easily shown that the term ^'^^ is an upper-bound on the time at which 
J„ starts its execution, i.e., its dispatching time. Therefore, the whole expression can be interpreted as follows: 
upper-bound on the makespan = upper-bound on the dispatching time of J„ + c„, where J„ is the (or any) 
job with the largest processing time. That is, this expression of ms"^°"*( J, vr) is based on the intuition that the 
maximum makespan is reached when the longest job is dispatched as late as possible and executes for its WCET. 
This intuition has revealed to be true for the case of identical platforms, but not for the uniform case (as shown 
by Example 101^ The whole concept is not extendable to uniform platforms and in order to figure out the 



underlying cause, let us focus on Example [To] 

Let 5""^'^° and S'™^ denote the two schedules depicted in Figure 20 issued from the approximation msQ"'^( J, tt) 
and from the priority assignment Ji > J2 > J3 which leads to the maximum makespan, respectively. The reason 
why msQ"'*( J, tt) under-approximates the maximum makespan comes from the following fact: if t denotes the 
instant at which job J3 is dispatched to CPU tts in 5""^ (here, t — 12), then during the time interval [0, t], J3 
has executed a lower amount of execution units in the stairs of S""^ than upon in 5'"'^'™. In other words the 



cumulated green areas in Figure 20 represent a lower amount of execution units than the red area. Indeed, J3 
executes 5 + 14 = 19 execution units within [0, t] in S™^ whereas it executes 20 execution units on tt^ in 5'"aive_ 
As a result, the remaining processing time of J3 at time t is higher in S™^ (here, 80) than in S'"aive (j^gj-g^ 79)^ 
implying that J3 completes later in 5'"'^ than in 5"*^'™. This is the reason why the expression msQ"'^( J, tt) does 
not provide the maximum makespan in the example above: on uniform platforms, the schedule in which any job 
Ji reaches its maximum completion time is not necessarily the schedule in which Ji is dispatched as late as possible. 

Based on this fundamental observation, we propose and prove correct in [28] (pages 138-163 and 351-367) 
two additional upper-bounds ms2'"^(J, tt) and niS3""^(J, vr) on the maximum makespan, considering uniform 
platforms and FJP schedulers. These upper-bounds are replicated below. 

msr'iJ, ^) — • > ' I C, + Si • I • X„_,; (17) 




where Kj is such that Vj, 




if Sl — Sm and j — 
otherwise 



^^Indeed, we can also easily show that the term ^J^IL/ in Expression |lo| is an upper-bound on the dispatching time of J„ and 

at that time J„ is dispatched to the fastest CPU nm, leading to a WCET of — . 
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and 



where 



unif / 7 ^ dcf 1 V"^ / Sx ■ S 

msg (J,7r) = 2^\ce 



Ei-1 
.1=1 



j=l 



(18) 



X = argmm 



and Hj is such that Vj, 




i e [1,™] [ Z]}=i J 

if = J2^i=i Si and j = 
otherwise 



Each of these two upper-bounds is based on a distinct upper-bound on the amount of execution units that 
can be executed in the green areas (see Figure [20]), and then derives an upper-bound on the completion time of 
every job, and finally on the makespan. 

8.5 Validity tests for SM-MSO and AM-MSO 



From Expressions [141 17 18 and Corollary [T] a sujficient validity test for the protocol SM-MSO can therefore 
be formalized as follows. 

Validity Test 4 (SM-MSO, uniform and FJP) For any multi-mode real-time application t and any uniform plat- 
form TT — [si,s2, . . . ,s,„] composed of m CPUs, the protocol SM-MSO is valid provided that, for every mode 

M\ 

^^{Jr, ^) < mm jmjn {l?i(M^)} 
where ms^SifC^"^', i") ^ defined as nTs™;|( Ji^^ tt) =^ 

min { msr {Jr ^T'^ (Jr^^)< { Ji"" , } (19) 



and msi'"^(Ji*^7r), ms™" {J.;"" , ?:) and ms™" ( J^^^ tt) are defined as in Expressions\l^^and^ respectively. 
This is performed considering the set J^'^ composed of iii jobs of processing time , Cj, . . . , C*^. such that Cj > 
q_iVj = 2,3,...,ri,. 

Concerning the protocol AM-MSO, the upper-bounds idlefe(J^^'^, tt) (for all 1 < A; < m) defined as in 
Lemma 14 can be used at line 10 of the validity algorithm given by Algorithm 10 (on page 15 1. 



8.6 Simulation results 

Because our analysis of the competitive factor did not lead to a constant a for the upper-bound nis""'^( J, tt) 
(as well as for the upper-bounds ms2"'^(J, tt) and ms3'"^(J, tt) as shown in I128II ). this section reports on the 
results of simulations in order to quantify the precision of the three upper-bounds ms'j""^( J, tt), ms2"'^( J, tt) and 
ms3"'^( J, tt). These simulations are performed considering a single set J of jobs scheduled and multiple uniform 
platforms. We consider only a single set J of jobs for which the exact processing times are given in Table [s] We 
will explain below where these parameters are drawn from and why we consider only a single set of jobs rather 
than generating numerous job sets. 



Cl 


C2 


C3 


C4 


C5 


3896 


3964 


878 


1378 


2228 








cg 


ClO 


3612 


1230 


1232 


1668 


4672 



Table 5: Processing times of the 10 jobs in J. 

For experimental purposes, let us introduce the parameter \^ defined in [11811 for any m-processor uniform 
platform tt = [si, S2, • ■ ■ , Sm], 

, dcf m I X]'fc=l Sk I 

= max < " — > 
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Informally speaking, this parameter Att measures the "degree" by which tt differs from an identical multi- 
processor platform, i.e., its "degree of heterogeneity". For any identical platform composed of m CPUs, it 

holds that si = S2 ^ ■ ■ ■ — Sm and thus, A^r =^ max™^^ | ^'T^ | maximum for j — m, leading to 
dof Efc=i sfc _ m — 1. The more homogeneous the platform tt is, the closer to (m — 1) is its corre- 
sponding AjT. For instance, the uniform platform tt = [1,500,1000] has a corresponding A^r = ~ 0.5 
whereas A^ = = 0.835 for the uniform platform it = [1,500,600] and A^ = ^ sa 1.67 for the platform 
TT = [500,500,600]. In short, X^^ ~ {m — 1) if tt is comprised of m identical CPUs and becomes progressively 
smaller as the speeds of the CPUs differ from each other by greater amounts. 

The platform tt considered in our simulations is composed of m = 4 CPUs for which we make their comput- 
ing speed var5dng within [1, 101] with an increment of 10. More precisely, we consider all possible combinations 
of the CPU speeds in the range [1, 101] with an increment of 10, i.e., the first simulation is performed consid- 
ering TT = [1, 1, 1, 1], the second simulation considers vr = [1, 1, 1, 11], the third one considers tt = [1, 1, 1,21], 
and so on until reaching the speed assignment tt = [101, 101, 101, 101]. For every speed assignment, we de- 
termine the corresponding parameter A„ as well as the exact value ms( J, tt) of the maximum makespan. This 
exact maximum makespan ms(J, tt) is determined by building the schedule of J upon tt for every job priority 
assignment and by retaining only the maximum generated makespan. This is a highly computational-intensive 
operation that requires the exhaustive enumeration of every possible job priority assignment. This is the reason 
why we consider only a single set J of jobs in our simulations. Indeed, according to this approach, our simu- 
lation process considers 11 different speeds for each CPU, leading to a total of 11™ = 11"^ = 14,641 different 
platforms tt. For each platform tt, the computation of the exact makespan requires to generate the schedules 
derived from every job priority assignment. Since there are 10 jobs, the number of considered priority assign- 
ments is 10! = 3, 628, 800. MultipHed by the number of platforms, this leads to 53, 129, 260, 800 operations. 
Our simulations were performed on HYDRA, the Scientific Computer Configuration at the VUB/ULB Computing 
Centre, where we fully distributed the computations among 15 processors AMD Opteron dual-core @ 2.8GHz. 
Distributing the computations allowed us to complete the simulation in about 2 hours but unfortunately, the 
computation time grows exponentially with the number of CPUs and in a factorial manner with the number of 
jobs. For instance, considering 13 jobs would result in 91, 169, 811, 532, 800 operations, 14 jobs to approximately 
20 • 10^^ operations, resulting in a computation time of about 82 years. The processing times of the jobs have 
been drawn from [15] where the authors present realistic parameters that concern the avionic domain. But 
since the number of operations of our algorithm is strongly restricted by the number of jobs, we arbitrarily 
selected 10 WCETs from these parameters. 

For each speed assignment of the platform we computed the error J, tt) corresponding to the difference 
(in percent) between ms"'^'*( J, tt) and nis( J, tt). Formally, 

ms( J, tt) 

and in a similar way we also computed the errors E2™^{J, tt) and i?™'' (J, t t). 

The errors iJ™'' (J, tt), E™^^{J, tt) and £^3'"^( J, tt) are displayed in Figure 21 relative to the corresponding A,r- 



The horizontal black line is the error "E_EXACT_MAKESPAN" of ms( J, tt) over the exact value of the maximum 
makespan. Obviously, this erro r is always 0. Also, for every speed assignment of tt, we define the estimator 

relative 



msjjj"„ ( J, tt) as in Expression 19 and its associated error E™]^ ( J, tt). This error is displayed in Figure 
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to the corresponding A^r. Finally, Table [6] provides the reader with some statistics issued from the simulation. 

For obvious reason, the most accurate estimator (i.e., the most accurate upper-bound on the maximum 
makespan) is ms,™j|^( J, tt). As presented in Table|6] the most important error that we obtained for ms^"[f ( J, tt) is 
22.89% and the minimal one is 1.57%. The average error is 10.44% with a squared distance of 5.78%. Hence, we 
believe that this is a promising path to go for more competitive bounds and for practical use. An open question 



remains however For A^ S [0, 2], we can see in Figure 21 that nis™'^( J, tt) is clearly lower than both nTs2"'^( J, tt) 
and ms3""( J, tt), i.e., ms^if ( J, tt) = ms™'^( J, tt) for A^ e [0, 2]. Within this interval [0, 2], when the parameter 
A^ reaches an integer value (here, 1 and 2), something happens that considerably improves the accuracy of 
ms™Jj^( J, tt). But up to now, we did not find any interpretation to that phenomenon. 



9 Uniform platforms and FTP schedulers 

This section follows the same reasoning as the one for identical platforms and FTP schedulers. For any transition 
from a specific mode AP to any other mode AI\ the knowledge of the critical rem-job set J^'^ and the fact that 
the priorities are known beforehand enable us to compute the exact maximum idle-instants idle^, 1 < k < m, 
simply by simulating the scheduling of the critical rem-job set and by measuring the idle-instants idle^,, 1 < fc < 
TO, in that schedule (from Corollary [T] presented on page |19|). Thus, each idle-instant idle^ measured in the 
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Figure 21: The three estimation errors i?J""^(J, tt), iJ^'^C./, tt) and E™'^{J,tt) displayed relative to the corre- 
sponding X„. 
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Figure 22: The estimation error J, tt) displayed relative to the corresponding A 
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Table 6: Statistics issued from the simulation 



schedule of the critical rem-job set is an upper-bound on the idle-instants idlcfe in the schedule derived from any 
other set of rem-jobs. In conclusion, FTP schedulers enable us to determine the exacip^ maximum idle-instants 
idlcfc, 1 < fc < m, rather than over-approximating them (as done for the FJP schedulers). 



9.1 Upper-bounds idlefc( J, vr, P) on the idle-instants 



Lemma 16 provides the exact values of idlej(Ji, tt,?^) Vj e [l,m],i e [l,n] and VP, assuming that every 



job Ji executes for its WCET. However, in this particular case of FTP scheduler, we redefine the idle-instants 
idlcj {Ji,n,V) as follows. 

Definition 17 (Idle-instant idlej (Ji, tt, "P)) If denotes the schedule upon tt of only the jobs with a higher (or 
equal) priority than Ji according to V, then idlej(Ji, tt,?^) is the earliest instant in at which at least j CPUs 
idle. 

The only difference wrt. the previous one resides in the "higher for equal) priority than (...)". The reason 
for this redefinition is that, with the previous one, it was not possible to express the idle-instants id\cj{J,T:,V) 
(for j 



1, . . . , m) as in Definition 



13 



(page 141. Indeed, these idle-instants idlej{J,n,V) consider that every 
job of J are scheduled while the previous definition of the idle-instants idle j{Ji,'K,V) requires a job index i 
and considers that only the jobs with a higher priority than Ji are scheduled. Thereby, this previous definition 
always excludes the job Ji in the computation of the idle-instants. Now, thanks to this new definition, the 
idle-instants idlej{J,T:,V) (for j = l,...,m) can be expressed by idlej( Jiow, tt, T-"), where Jiow is the lowest 
priority job according to V. Once again, we use in Corollary |6] the notations idlc^ to refer to the idle-instants 



idle^ ( Ji, TT, V) defined as in Definition 17 



Lemma 16 (See [27|) Let n = [si,s2, - ■ ■ , Sm] denote any uniform multiprocessor platform composed of m CPUs 
and assume that Si > Si^i, Vi — 2, 3, . . . , m. Let J — { Ji, J2, . . . , J„} be any set of n jobs, all released at time 
t = 0, with respective computation time ci, C2, . . . , c„. Let S denote any global, FTP and strongly work-conserving 
scheduler and suppose that J is sorted by decreasing S-priority, i.e., Ji >s Ji+i. If these jobs are scheduled by S 
upon n, then idle* is inductively defined as follows: 



Initialization: 



Iteration: 

for (i = 1 to ii) 
for (j = mto 1) 



idle' 



< j < m : 
VI < i < n 



idle° 



idle: 



dcf 



m+1 



def 



'idle}'^ if idle}- 1 idlej^l 
idle}-\ ebe if c, > ELi(idlefe+\ - idler^) • Sk 
idler' + (-'-i:^^i('dio-\-idicr^)-..) otherwise 



(20) 



''Exact in the sense that this value is actually reached if every job executes for its WCET. 
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time 



Figure 23: Staircase defined by the idle^ ^ 



dof 



Proof 16 Initially, the m CPUs idle and thus, idle" — 0, Vj, 1 < j < m. We find convenient to define idle^_^;^ — 
(X),Wi, which means that we have at most m CPUs available. In the following, we prove the correctness of the value 
o/idlc* (yj, 1 < j <m) assuming that idlc*^^ are defined (ij < m + 1). The idle-instants idlc^~^ define a staircase 
as illustrated in Figure^3\for the scheduling of jobs Ji, . . . , Ji-i. Thus, job Ji can only progress into the blue areas 
and two cases have to be distinguished: 



Case 1 idle* ^ = idle^^\, meaning that at least one CPU faster than ttj becomes available at time idle^ ^ (the 



blue area on CPU ttj is void in that case). This situation is depicted in Figure 23 



where idlej ^ 



idle?, 



idle* 



and the blue area is void on CPUs tt2 and n^. In this kind of situation, the job Ji is executed (if not completed) 
upon a faster CPU and the first instant at which at least j CPUs idle remains unchanged after having scheduled 
the job Ji, i.e., idle* = idle*"^. 



Case 2 Otherwise, Ji is dispatched to CPU ttj at instant idle*"^ and keeps executing on ttj as long as (i) no faster 
CPUs become idle or (ii) Ji completes. In the first case, Ji executes on -kj until the next idle-instant idle*^^, leading 
to the first sub-case idle* = idle*T|^p In the second case, Ji executes on CPU ttj but completes before time idle*I|^p 
Thus, the idle-instant idle* is the instant idle*^^ at which Ji was dispatched to Hj plus its remaining processing 
time on CPU vtj at time idle*~^. Since X]i=i(idle^~^ — idle^^\) • sj. corresponds to the amount of work that Ji has 
executed in the interval of time [0,idle*~^], its remaining processing time on CPU ttj at time idle*^^ is given by 



c.-EUi(idlc 



idlc^ 



leading to the second sub-case. 



Corollary 6 (See [27'|) The maximum idle-instant idlefc( J, tt, P) (Vfc € is given by idle^ computed as in 

lemma [76] 



Corollary 7 The maximum makespan ms™ (J, tt) is given by idle"^ computed as in Lemma 16 



9.2 Validity tests for SM-MSO and AM-MSO 

From Corollary[7j a sufficient validity test for the protocol SM-MSO can therefore be formalized as follows. 
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Validity Test 5 (SM-MSO, uniform and FTP) For any multi-mode real-time application t and any identical plat- 
form TT composed ofm CPUs, the protocol SM-MSO is valid provided that, for every mode M\ 



idle^•(J,-^^,5')< 



mm 



mm 

k= 



w/iere idle;;,' ( TT, 5 

of Tii jobs Ji , J2 , . . . Jm of respective processing time , C2 , 
-priority. 



is computed as idle"^' in Lemma 16 considering the critical rem-joh set J^'^ composed 

, and such that J^^ is sorted by decreasing 



Similarly, the upper-bounds idlcfe( J, tt, T') (where 1 < k < m and V corresponds to the job priority assign- 
ment of the old-mode scheduler 5') determined in Lemma 16 can be used at line 10 of the validity algorithm of 



AM-MSO (see Algorithm 10 page 15 1, as long as these upper-bounds are computed while assuming the critical 
rem-job set J^™^ for the transitions from every mode M\ 



10 Conclusion and open problems 

In this paper, we addressed the scheduling problem of multi-mode real-time applications upon identical and 
uniform multiprocessor platforms. We assumed that every mode of the application was scheduled by following 
a global and Fixed-Task-Priority or Fixed- Job-Priority scheduler Under these assumptions, we proposed two 
protocols for managing every transition between every pair of modes of the system, namely SM-MSO and 
AM-MSO. For both protocols, we established validity tests that allow the system designer to predict whether 
the given application can meet all the expected timing requirements upon the given platform. We prove the 
correctness of our schedulability analyses by extending the theory about the makespan determination problem. 

In our future work, we aim at taking into account mode-independent tasks, i.e., tasks whose the periodic (or 
sporadic) activation pattern is not affected by the mode changes. Moreover, instead of scheduling the rem-jobs 
by using the scheduler of the old-mode during the transitions, it could be better, in term of the enablement 
delays applied to the new-mode tasks, to propose a dedicated priority assignment which meets the deadline of 
every rem-job, w/iik minimizing the makespan. To the best of our knowledge, the problem of minimizing the 
makespan while meeting job deadlines is not yet addressed in the literature and remains open. Table [7] outlines 
a brief overview of all different problems, considering the task and platform model introduced in this paper For 
each problem, we indicated either the reference(s) where solutions have been proposed or T.W. (This Work) or 
F.W. (Future Work) or CP. (Open Problem). 
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